Jedi/Sector One's random thoughts

Here is a cool demo of a clever technique that displays your browser history without using Javascript. Yep, not without any single line of Javascript.

Well done.

Marc Schoenefeld writes:

"regarding the regarding OSX java threat CVE-2008-5353 you can either join the current panic, or fix the issue in five minutes yourself.

If you belong to the second group of people you can follow the steps listed here, and also on http://www.illegalaccess.org

Basically the approach takes non-vulnerable classes from a fixed java version (like sun jdk 1.5.0_18 and makes it available to the OSX java class loader, which then fixes the issue). It is a non-intrusive fix, so it does not impair any patch (if any) that apple will rollout.

1. Get the src.zip of a recent non-OSX java distribution (like Sun Java 5/JDK 1.5.0_18 for Linux)
2. unzip src.zip java/util/Calendar.java
3. javac java/util/Calendar.java
4. zip /somepath/FixedCalendar.jar java/util/Calendar*.class
5. In ~/Library/Caches/Java/deployment.properties set option deployment.javapi.jre.1.5.0.args=-Xbootclasspath/p\:/somepath/FixedCalendar.jar
6. Start up a browser, browse to http://www.java.com/en/download/help/testvm.xml, see the dancing duke, open Java Console, press s, you should now see FixedCalendar.jar in the sun.boot.class.path
7. If you are brave, try the PoC exploit on http://landonf.bikemonkey.org/static/moab-tests/CVE-2008-5353/hello.html, it should give you a bootstrap failure now"

SecureThoughts.com has disclosed a frightening vulnerability in Internet Explorer 8: Exploiting IE8 UTF-7 XSS Vulnerability using Local Redirection.

That one is similar to an important issue that already affected Firefox and IE7.

But it looks like it hasn't been fixed for good. If a web page doesn't specify a charset, the browser can be tricked to load it with the charset of a malicious web site. And the deal is, that UTF7 doesn't encode characters like brackets the same way as ASCII, UTF8 or Latin charsets. If a page is rendered as UTF7 while, server-side, XSS-prevention mechanisms aren't aware that UTF7 is what the browser loaded the page as. And XSS-prevention mechanisms just become pointless, opening wide XSS holes.

Just read the scary details on the SecureThoughts web site.

And double check that every page you serve explicitely sents a charset.

CVS 2009-0065 have been described by Linux vendors as a remote denial of service.

Is it?

No, to tell the truth, the SCTP vulnerability is absolutely exploitable, with extreme reliability (nearly one-shot always) and an exploit is already out in the wild.

All you need is an application doing SCTP on the target host.

From KernelBOF.

The UK Center for the Protection of National Infrastructure just published a full roundup about security assessment of the Transmission Control Protocol.

This paper contains a complete and up-to-date coverage of potential and actual security issues of the TCP protocol, described in a very clear but extensive way.

Here's a link to a great how to written by Manjunath about setting up a highly available web server using Ucarp.

"Its amazing what an opensource package can do to your organization. We have already achieved 99.9999 on our webserver"

Here's the link : High Availability of Web Server Using UCARP

The whole Manjunath's blog also looks like a worthy addition to your RSS feeds.

Google just released their Browser Security Handbook.

This is a 60 pages document that provides a comprehensive comparison of a broad set of security features and characteristics in commonly used browsers, along with (hopefully) useful commentary and implementation tips for application developers who need to rely on these mechanisms, as well as engineering teams working on future browser-side security enhancements.

The author is Michal Zalewski, a well-known security researcher even before he joined Google.

Vietnamese security researchers from BKIS have done it once again, by demonstrating how some popular face-recognition systems can easily be defeated.

Here's a video about bypassing face-recognition systems.

Send9 found an exploitable heap overflow in the Opera web browser. Opera was notified around the time Opera 9.6 was released. Opera 9.61 and 9.62 were released since, but still no fix, so he released a public exploit for Opera 9.62. Very bad times for Opera, as every recent releases mainly addresses security flaws that weren't handled seriously when reported (see FM changelogs).

Another one you might care about: Plaintext Recovery Attack Against SSH, an attack verified on OpenSSH running Debian GNU/Linux.

Have phun.

The J-PAKE method (just implemented in OpenSSH and OpenSSL) allows password-based authentication without exposing the password to the server.

Instead, the client and server exchange cryptographic proofs to demonstrate of knowledge of the password while revealing nothing useful to an attacker or compromised endpoint.

Direct link to the the document: Password Authenticated Key Exchange by Juggling and to the announce (with links to source code in C and Java).

Yes, the issue is old, and yes, it has been widely disclosed and discussed everywhere.

So, is clickjacking a threat of past?

Unfortunately not. Clickjacking is still a real issue until everyone upgrades to Flash 10 (and until a variant is found).

Although it's only a partial barrier against clickjacking, something that any web developper should do on every web site if to check whether the site has been loaded as a frame (or iframe).

Really. As a bonus, it will defeat almost every web-based anonymous proxy, and it might prevent exploitation of cross-frame leaks.

Is there any downside? Probably none. It's something I'm doing for years (was to bugger people surfing through anonymous proxies) without any issue.

How to do it? Just add some lines of javascript that checks whether window.parent.location.href matches your domain. If it doesn't, set window.parent.location to window.location.href and you are done.

Maksymilian Arciemowicz published a cross-site request forgery vulnerability, affecting BSD FTP servers, ProFTPd and maybe others.

If you're running Pure-FTPd, even a very old version, keep cool, your server is not vulnerable. The Pure-FTPd command parser is a bit aggressive (it drops the connection if very large requests are received) but it avoids this flaw.

Stefan Esser published his Slide from the Zend Conference 2008 covering various common vulnerabilities in PHP applications and in PHP itself.

It's definitely worth a read.

The first real security flaw in Google Chrome has been disclosed by vietnamese researcher Le Duc Anh – SVRT member of the BKIS group.

This is a critical vulnerability.

Finally!

Dan J. Bernstein just published DNSCurve, a new link-level DNS security protocol that takes advantage of state-of-the art cryptography.

As a reply to Tobian Reckhard who raised the performance issues of RSA-and-Diffie-Hellman-secured connections as a proposal to secure DNS, DJB answered:

"On the other hand, those precomputed signatures have to be separatelyverified by each recipient. State-of-the-art protocols to encrypt and authenticate packets take more work for the first packet but allow very low-cost handling of subsequent packets between the same parties.

More importantly, the work for the first packet has been dramatically reduced in recent years. High-security 255-bit elliptic curves, billions of times more difficult to break than 1024-bit RSA by current attacks, can handle 1000 new communication partners in just 40 milliseconds on a Core 2 Quad with state-of-the-art software.

http://dnscurve.org describes a new link-level DNS security protocol that takes advantage of these advances in cryptographic speed. The protocol provides integrity (recognizing and discarding forged packets) and some confidentiality, while drastically simplifying implementation and administration compared to DNSSEC."

Does it still sound obscure? So have a look at the PDF presentation about DNSCurve. (check the part about Bind and DNSSec, very funny).

Actual solutions instead of marketing crap, that's why I love you, Dan!