Jedi/Sector One's random thoughts

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!

---D. J. Bernstein, Professor, Mathematics, Statistics, and Computer Science, University of Illinois at Chicago

DNS still vulnerable, Bernstein says.

CHICAGO, Thursday 7 August 2008 - Do you bank over the Internet? If so, beware: recent Internet patches don't stop determined attackers.

Network administrators have been rushing to deploy DNS source-port randomization patches in response to an attack announced by security researcher Dan Kaminsky last month. But the inventor of source-port randomization said today that new security solutions are needed to protect the Internet infrastructure.

"Anyone who knows what he's doing can easily steal your email and insert fake web pages into your browser, even after you've patched," said cryptographer Daniel J. Bernstein, a professor in the Center for Research and Instruction in Technologies for Electronic Security (RITES) at the University of Illinois at Chicago.

Bernstein's DJBDNS software introduced source-port randomization in 1999 and is now estimated to have tens of millions of users. Bernstein released the DJBDNS copyright at the end of last year.

Kaminsky said at the Black Hat conference yesterday that 120,000,000 Internet users were now protected by patches using Bernstein's randomization idea. But Bernstein criticized this idea, saying that it was "at best a speed bump for blind attackers" and "an extremely poor substitute for proper cryptographic protection."

DNSSEC, a cryptographic version of DNS, has been in development since 1993 but is still not operational. Bernstein said that DNSSEC offers "a surprisingly low level of security" while causing severe problems for DNS reliability and performance.

"We need to stop wasting time on breakable patches," Bernstein said. He called for development of DNSSEC alternatives that quickly and securely reject every forged DNS packet.

Read on: OpenSolaris remote root exploit

No, it's even not a joke :)

Just as good as the telnet -l -froot vulnerability, also available on AIX.

It looks like details for the DNS vulnerability reported by Kaminsky have been leaked

Although it's still a shame to call the a "DNS vulnerability" as some implementations (djbdns) never were vulnerable to this.

Yet another vulnerability in the PAM code of OpenSSH-portable. A basic format-string bug. Of course if you are running FreeBSD, the base OpenSSH is as affected as the port. Of course, almost every Linux distro is affected. And of course the latest release (5.0) is affected.

Simple fix:

Edit auth1.c and replace

        packet_disconnect(msg);

with

        packet_disconnect("%s", msg);

OpenBSD is not affected, this is only in OpenSSH-portable.

Published today by Mrdkaaa for the pwnie awards.

Update: it doesn't seem exploitable in the real world, though, see That thread, pointed out by Greg (thanks!)

It's a sad day. Jun-Ichiro Itoh Hagino "Itojun" has passed. Funeral services will be held on Nov 7th at Rinkai-Saijo in Tokyo.

Itojun was a respected programmer, an IPv6 pioneer who made wonders in working on the KAME project.

OpenBSD, NetBSD, FreeBSD and DragonflyBSD IPv6 stacks are mostly Itojun's work. Itojun was a very nice guy and he had an amazing knowledge of every aspect of IP networks.

We will all miss him. Rest in peace, Itojun.

See more information in japanese on hoge.org and on Undeadly. Here was his personal web page.

You can't have missed it, a vulnerability in OpenSSL's SL_get_shared_ciphers() function has been discovered.

All vendors have pushed a fixed version of the library, and some of them tagged the vulnerability as critical.

What package does it affect? Does it affect Apache SSL and OpenSSH?

Okay, calm down, here's a quote from Phillip Guenther from the OpenBSD team:

"The only code in the main OpenBSD tree that calls SSL_get_shared_ciphers() is the openssl(1) utility's s_client and s_server modes. However, that code passes the function a buffer of size BUFSIZ (== 1024) while the complete list of ciphers is only 666 bytes, so it's impossible to hit the overflow there.

The only other code that I've ever seen that calls that function is the perl Net::SSLeay module, which simply provides access to OpenSSL functions from perl. Maybe there's a perl script out there that uses that, but I haven't seen one.

The function itself is almost useless; the only reason I can think to call it would be if you were debugging the cipher selection algorithm in OpenSSL."

Vulncheck is a very handy static source-code analyzer for GCC. It's not a competitor for Coverty, but it still can help a lot to discover some possible bugs and vulnerabilities.

Vulncheck has just been updated to GCC 4.2.1. Check out the Vulncheck web site in order to read the paper and to download the patch.

"Imagine you’re a web advertiser. Imagine you can open a popup window from a web page defeating any popup blocker. Imagine this popup can invade the whole desktop, full screen. Imagine this popup has no title bar, no menus, no toolbar, no location bar, no border and no buttons. No mean to close it. Imagine user can’t move or minimize this popup. It will go away only when the browser is killed or your show is done…

Now imagine you’re a phisher. Imagine you can use this almighty popup to draw anything you want. A fake browser or — why not? — a whole fake desktop to collect user’s data.

Impossible wet dreams of clueless evildoers?"

Have a look at Giorgio Maone’s scary article about how Java and Javascript can be abused.