>I've downloaded this fixed version, but it seems to be vulnerable to
>something I've discovered last week: if you take a .swf and rot13 encode
>it (not all of it, so the headers are not messed up), you can crash the
>user's browser.

There are quite literally a thousand ways to crash the Macromedia Flash
player (at least the version in use a year ago, when I was dealing with
it). The majority of mistakes one makes, and bugs one finds, when
attempting to create an SWF-writing application will kill the player: about
a quarter of them will crash the player (and browser), the remainder mostly
cause the player's memory usage to shoot up to about 40-70mb and then hang.

A surprisingly large number of these faults can be triggered just using the
Macromedia SWF SDK, without any mucking around with the binary SWF files,
although you do have to fix a number of bugs in the SDK before you can get
to that stage (which I won't go into here - Macromedia seem to have made a
habit of suing anyone who tries to distribute bugfixes for their SDK).

Anyway, getting back to the security issues, while crashing the browser is
definitely unacceptable I'm not yet sure if any of those crashes would be
exploitable, as most of them seem to be due to problems with their
algorithms (as opposed to say simple string buffer overflows) - stack
overflows due to recursion, null pointer violations, that kind of thing.

Further experimentation would be warranted. I'd recommend starting with
the audio compression, image compression, and font handling, as since they
involve buffer decompression etc. there's a better chance they're
susceptible to buffer overflows.

Cheers,
Will

_______________________________________________________________________
Will Bryant, willcore-dev.co.nz cell +64 21 655 443
http://www.core-dev.co.nz/ Personal: http://carcino.gen.nz/
[PGP 0x96A7F40A, FP 827F A2A9 C718 106D 8F80 E16E A244 D5F2 96A7 F40A]

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]