Another round of image bugs: PNG and JPEG XR | Hacker News Reader

Another round of image bugs: PNG and JPEG XR

lcamtuf.blogspot.com

91 pointsrobin_reala37 comments

Now that we have an OCaml SSL implementation, has anyone put together a roadmap for building up to a complete browser in OCaml?

It would be the work of a decade or more to rewrite image parsing, HTML rendering and all the rest of it, but I honestly think it's the only way we're ever going to get decent security.

The other way is Rust :) https://github.com/servo/servo

Interestingly Mozilla are looking at parts of Gecko that could be rewritten in Rust as an early win (instead of rewriting the entire thing) and image decoding comes up pretty often as a candidate.

I'm wondering about Mozilla's plans with Servo. Granted, it's a layout engine and the majority of these bugs creep up in low-level data processing (such as in this example) but it's a necessary step towards writing a browser using "safe" technology.

Now we only depend on the security of compilers and VMs for these languages :)

Servo is an experimental platform and is not intended for production. Hopefully people will learn from it when making future projects though.

Where did you get that idea? Servo is designed to become a production-quality Web engine.

(Source: I'm one of the "founders" of Servo.)

Oh! I got it from the big disclaimer at the top of http://paulrouget.com/e/servo/

Last I knew they didn't have much in the way of defence against timing side-channels, which pretty much rules it out for any real deployment.

Don't they? I'd think someone would crack the bitcoin piñata if so.

Bitcoin piñata http://ownme.ipredator.se/ https://news.ycombinator.com/item?id=9027743

Not everything in a SSL implementation needs constant-time operations. For example, something like ASN.1 parsing (which is a huge PITA do in C and has led to vulnerabilities in the past) could very well be done in OCaml.

It's true that some languages, by their very nature, make exploits like buffer overflows impossible, but if a browser was to be built with entirely new code for this reason, I'd be much happier to see it built on a VM such as a JVM or a CLR, so more widely-known language[s] could be used for development.

Both the JVM and CLR have heap compaction pauses that make them unsuitable for even soft realtime (e.g. video streaming), which is something we want browsers to be capable of. You need either pauseless mutable heap compaction (something only Azul's super-expensive JVM does AIUI, and it requires a modified kernel to do it), a mostly-immutable language (OCaml, Haskell etc.), or explicit but safe memory management (pretty much a new thing in Rust).

The Java plugin used to have a lot of security advisories (well maybe not as many as browsers, but still) and Mozilla had to blacklist certain versions: https://addons.mozilla.org/en-US/firefox/blocked/

If the Java plugin itself has security vulnerabilities how can we expect a full browser written in Java to have none?

The Java plugin was trying to do the approximately impossible: run untrusted code that had direct access to all the primitives of a full, first-class programming language. Flaws in the VM security would not compromise the security of a browser written in Java (they might make it hard to e.g. implement a secure plugin system for your browser - but Mozilla doesn't even try to not trust extensions, they rely on signing and allow a signed extension to do anything)

The Java plugin was trying to give the ability to use Java, which could control all aspects of your machine, without them being able to control all those aspects of your machine. I can't create a javascript that installs a C&C silently in the background, but Java by default would allow all sorts of issues as it isn't sandboxed.

The Java plugin was the attempt to build a sandbox. The problems occurred because it is vastly easier to build a sandboxed language from the ground up than to sandbox a language with full access.

There was an experiment using Webkit: http://caravel.forge.ocamlcore.org/

I don't know if its possible to gradually replace Webkit's components with OCaml...

I think I need to write a "C Programming Language Considered Harmful" essay. In this era, using a language which allows buffer overflows, heap corruption, use-after-free, integer overflow, and eliminates "undefined" but security-critical code, is utterly irresponsible for anything where security matters - and that is virtually anything, given the complexity and interactions in modern systems.

All code should have mandatory, compiler-enforced integer overflow and bounds checks at the very least.

We should have settled on Pascal long ago :-)

I feel like that too — but then I read something like this http://thread.gmane.org/gmane.comp.version-control.git/57643... and I begin to think that may be I just feel that because I'm a OOP, garbage-collected brought-up weakling who doesn't comprehend the wisdom of the C wizards.

...huh?

This has nothing to do with C's imperative, procedural, low-level programming style. It has everything to do with safety.

No, that's Linus choosing to offend people. It's not that he's entirely wrong about portability and stability of modern C++ in 2007, and it certainly introduces a whole new wave of ways to shoot yourself in the foot, but some of the conveniences are genuine improvements.

This was already clear to many of us Modula-2/Turbo Pascal developers back in the mid-90's, but then C won thanks to UNIX adoption.

- Array implicit decay into pointers instead of requiring an explicit "address of" operator

- No bounds checking

- Implicit conversion between enumerations and numeric types

- Implicit conversions between numeric types

- Null terminated strings

Every time I had code in straight C, I made it look like Pascal by validating all the parameters, compiling with all warnings enabled, warnings as errors, using ADTs with no field access to structs.

A static analyzer is also compulsory.

The amount of money caused by bug fixing in developer time, creation of C memory corruption detection tools and paying for them is just endless.

Oh, right, I forgot about null-terminated (aka "C") strings! But you'd have to get rid of them for bounds-checks anyway.

Nah.

You can deal with null-terminated strings.

You "just" have to be able to prove that all operations ensure a string remains postpended with a null, and doesn't get extended beyond the length of the underlying allocation.

UNIX and Windows adoption. I think until at least the mid-90s everyone had a "performance at any cost" mentality as well, which has now become less critical as the hardware is so fast.

C didn't had any big meaning in the MS-DOS days.

By the time Windows was starting to be developed, UNIX was already established in the industry and was only natural to take ideas from it.

But yeah, eventually it also helped disseminate C. It was by then that I moved from Turbo Pascal into C++.

I think many people agree with this but it's not clear how we get there with most of our critical code written in C. I think a lot of places have decided to invest in better tooling (see e.g. Clang's stable of sanitizers) as a shorter-term option while hoping that an alternative matures.

http://www.jwz.org/doc/worse-is-better.html

It seems that Safari 8.0.3 on OS 10.10.2 is also affected by the PNG bug. Although it has a variable number of variants each time the page is open/refreshed (don't have access to a vulnerable IE to test if it has the same behaviour)

It might be the case that the variants aren't exploitable – Safari uses CoreImage and that framework tends to bend over backwards to support malformed images so I wouldn't be surprised to see it render differently for each slightly different test image even if none of them are exploitable.

But isn't the idea here that all the "variants" are actually the same exact .png byte stream? So any differences are the result of leaking memory...?

You're right – the random call is just a dodge around caching. It could be leaked memory or possibly something like an address dependency but I'd hope that he submitted it to Apple along with the other browsers he's been testing.

It's also acting up in iOS on mobile safari. And, even more interestingly, if you long-tap a few of the images and save them to the photo stream, you'll see them change "live" in lots of applications like the photo browser, photo editors, pasting in an iMessage, etc.

Yep, another example of C features.

I am really looking forward that the likes of D, Go, Rust, .NET Native, Ada, ParaSail, Chapel, Java (past v10) and many others help reduce even more the need for C to the same level as Assembly use nowadays.

Seriously, how does one go about discovering obscure exploits like these?

Well, fuzzing, apparently:

> Similarly to the previously discussed bugs ... these two were found with afl-fuzz.

http://lcamtuf.coredump.cx/afl/

You write a fuzzer: http://lcamtuf.coredump.cx/afl/

Reply on news.ycombinator.com