>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, will@core-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]
