Archive for the Java Category

Nir Goldhsanger asked me to share with my audience a nice privilege escalation through parameter pollution he found, allowing the attacker to become administrator of any Blogger blog, which he dutifully reported to Google and deserved him the famous $1337 bug bounty.

I’m quite impressed by the first step of the attack, where the application gets fouled by a double “blogID” parameter: the first gets validated (it actually refers to a blog owned by the attacker) but then the second is actually used to perform the “add authors” action. Looking at the URL, it would seem they use Struts or some other Java-based framework. Since I’m quite rusty with them (these days I mainly use PHP and Ruby on the server side), would anyone attempt a reverse engineering and explain which kind of code could get messed by this? Did they maybe parse their parameters twice, with two different parsers?!

An old Java vulnerability, already fixed 6 months ago in every Java implementation except Apple’s, allows remote attackers (i.e. malicious web sites) to launch arbitrary code from Safari or Firefox with full user privileges, evading the Java applet sandbox on Mac OS X.

Here’s the Slashdot’s routine Apple+Java bashing with linked source articles.

At this moment, the easiest way to protect your Mac web browser is either turning off Java globally or… you know what ;)

Update Jun 15th

Three weeks later, Apple finally patched..

A Firefox 3.0.8high-priority fire drill security update” is on its way, likely to be released by the middle of next week (April the 1st at most, jokes aside). The reason is an emergency patch for a critical vulnerability irresponsibly disclosed by Guido Landi. I feel a bit guilty about it because Mr. Landi is Italian like me — not that here in Italy we lack reasons for being ashamed…

Beware the PoC: it will crash Firefox on Windows, Linux and Mac OS X even if you’ve got NoScript. However this crashing bug, like the vast majority of them, is not exploitable if you’ve got JavaScript and other active content disabled on the attacker site, because reliable exploitation requires scripting to “spray the heap”, i.e. to inject the malicious payload at the right places of your memory for execution.
Therefore you can easily survive until the automatic update kicks in, if you don’t mind the possibility of an annoying but not dangerous crash (thanks, session restore!) ;)

On a side note, it’s time to update Java as well: yet another bunch of critical vulnerabilities, several of them exploitable in your browser. Business as usual…

Important updates here.

Did you know crossdomain.xml, introduced by Adobe Flash to allow cross-domain requests, is now supported by Java?

A similar mechanism is being standardized for XMLHttpRequest, and had been implemented in an early Firefox 3 beta (some extra work for your friendly neighborhood NS-Man), but ultimately dropped later in the development cycle…

Rhino VS BeanEven if I’m the NoScript guy, I write a lot of JavaScript all the day. As you probably know, even the JavaScript Annihilator is mostly written in JavaScript. Like Crock, I love the language, despite its current browser-bound shortcomings.

So far, my favourite editor for JS coding has been JEdit with its JavaScript plugin, providing syntax highlighting (of course!), on the fly syntax checking via Rhino and optional code completion with configurable scopes, including Mozilla “chrome window” and XPCOM.

But today I’ve watched a presentation of the new NetBeans 6.1 JavaScript capabilities, and I’m impressed.
Dynamic type guessing, browser-specific contextual help and DOM-aware AJAX library support (John, guess which they show in their demo?) may be really worth the switch.

Bad Behavior has blocked 2727 access attempts in the last 7 days.