>Depends on your malloc() implementation. The thing that causes the bug >to appear is an input stream constructed *just* *so*, and that *is* >platform independent as the inflate input stream is the same regardless >of platform. Bad things happen when malloc()/free() from libc is also >faulty or fails in a certain way upon a double free. The best you can >hope for is a segv, still a downer for the user.
If it's only inflate that's faulty, doesn't that exclude all current VNC servers from the vulnerability? They only deflate, not inflate. Of course, it also changes the severity of the vulnerability significantly - the exploit happens on the viewer end, which is often more useful than on the server end, and an attacker need only be able to modify the stream going back to the viewer. >Most libc's are related - I wouldn't be surprised if MacOS X's malloc is >related to BSD or gnu's libc. But it also depends on your compiler - if >Metrowerks have a compiler suite for MacOS X that's not the heavily >modified gcc that Apple supply, then that could be a dependency. As far as I can tell, the Metrowerks compiler is unrelated to GCC, and the malloc() implementation on Classic MacOS is also unrelated to BSD libc. However, I have no clue what compiler Dair uses for VNCThing, and the Carbon API probably translates malloc() into a libc call when under MacOS X. >Suffice to say, it's simpler to re-link with zlib 1.1.4 than to figure >out if you're actually vulnerable to the input stream. Yes, and fixing that bug is always good whether it closes a hole or not. The hole just makes it more urgent. -- -------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) website: http://www.chromatix.uklinux.net/ geekcode: GCS$/E dpu(!) s:- a21 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) tagline: The key to knowledge is not to rely on people to teach you it. --------------------------------------------------------------------- To unsubscribe, mail [EMAIL PROTECTED] with the line: 'unsubscribe vnc-list' in the message BODY See also: http://www.uk.research.att.com/vnc/intouch.html ---------------------------------------------------------------------
