Subject: Re: Wierd bugs are cool bugs. (or as halvar would say "deep sea fish are good eatin'!") - msg#00030

Previous Message by Date: click to view message preview

Re: Wierd bugs are cool bugs. (or as halvar would say "deep sea fish are good eatin'!")

Well, it gave me a pretty girl picture and a plethora of garbage, all followed by "Hello cruel world." But no crash. It really pays to NOT use IE. $.02 Moe -------------------- Dave Aitel wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The below email (not from me) is an interesting and weird bug and I > felt it merited some notice. > > - -dave > > _____________________________________________________________________________ > > From: Michael Zalewski - lcamtuf@xxxxxxxxxxxx > > Good morning, > > This might not come as a surprise, but there appears to be a *very* > interesting and apparently very much exploitable overflow in Microsoft > Internet Explorer (mshtml.dll). > > This vulnerability can be triggered by specifying more than a couple > thousand script action handlers (such as onLoad, onMouseMove, etc) for any > single HTML tag. Due to a programming error, MSIE will then attempt to > write memory array out of bounds, at an offset corresponding to the ID of > the script action handler multiplied by 4 (due to 32-bit address clipping, > the result is a small positive integer). > > The list of IDs can be found on the Web, and is as follows (values in > parentheses = resulting offsets): > > onhelp = 0x8001177d (+0x45df4) > onclick = 0x80011778 (+0x45de0) > ondblclick = 0x80011779 (+0x45de4) > onkeyup = 0x80011776 (+0x45dd8) > onkeydown = 0x80011775 (+0x45dd4) > onkeypress = 0x80011777 (+0x45ddc) > onmouseup = 0x80011773 (+0x45dcc) > onmousedown = 0x80011772 (+0x45dc8) > onmousemove = 0x80011774 (+0x45dd0) > onmouseout = 0x80011771 (+0x45dc4) > onmouseover = 0x80011770 (+0x45dc0) > onreadystatechange = 0x80011789 (+0x45e24) > onafterupdate = 0x80011786 (+0x45e18) > onrowexit = 0x80011782 (+0x45e08) > onrowenter = 0x80011783 (+0x45e0c) > ondragstart = 0x80011793 (+0x45e4c) > onselectstart = 0x80011795 (+0x45e54) > > What happens next depends on the structure of the page in which the > malicious tag is embedded, as well as previously visited page and > previously initialized extensions (all these factors can be controlled by > the attacker). > > When the offending page contains no additional elements, and the user is > not redirected from elsewhere, the browser will typically crash > immediately, because there is no allocated memory at the resulting offset. > In all other cases, crashes will typically occur later, due to attempted > use of unrelated but corrupted in-memory buffers -for example, when the > user attempts to leave or reload the page. Another good example is coming > from a page that contains Macromedia Flash - this usually causes the Flash > plugin itself to choke on corrupted memory on cleanup. > > For non-believers, there's a short but fiery demonstration page available > at http://lcamtuf.coredump.cx/iedie.html (yes, it will probably crash your > browser). > > Tested on MSIE 6.0.2900.2180.xpsp2.040806-1825 on Windows XP SP2. As far > as I can tell, other browser makes (Firefox, Opera) are not susceptible to > this attack. > > I eagerly await due reprimend from Microsoft for not disclosing this > vulnerability in a manner that benefits them most, not passing start, not > collecting $200 (from iDefense?). > > Regards, > /mz > http://lcamtuf.coredump.cx/silence/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFEGes4B8JNm+PA+iURAsZsAJ0XGy+wgQVYxD1THdhkuTpw7pLnQgCaA03g > gBd30LhoXNtpVYFXWZNYzko= > =f+Yl > -----END PGP SIGNATURE-----

Next Message by Date: click to view message preview

Re: Generically Determining the Prescence of Virtual Machines

Nice work val! :) I looked at this a short while ago as well, and ended up using a redpill style determination of virtualization, but I also wanted to know what kind of virtual machine I’d landed myself in.  A few people pointed me at the back door attacks for vmware and virtual pc, but after some testing I determined that they were none too stable. (They crashed and burned on non-virtualized linux...) So I cheated and simply queried the first scsi device for a vendor and this works pretty well ;)  Certainly, you could create a vmware machine that didn’t use scsi drives, but that seems pretty rare as it’s the default. Seems like I ought to update my code to use your technique though ;) http://daemonkitty.net/MSF3/isvirtualized.asm On 3/16/06 8:00 PM, "valsmith" <valsmith@xxxxxxxxxxxxxx> wrote: At OffensiveComputing we were looking at ways to detect virtual machines and had found and discarded many unsophisticated methods such as looking for VMWare Tools running as a service or VMWare related registy keys, etc. Then we discovered Joanna Rutkowska's very interesting "Redpill" method. This was an eye opening work for us. After spending a little time playing with it we realized it wasn't fool proof on multiprocessor systems and so we decided to research the problems and possible ways to improve on the method. We discovered and implemented an improved method which is presented in the this paper. Check http://www.offensivecomputing.net for the paper. V. ~ Puss

Previous Message by Thread: click to view message preview

Re: Wierd bugs are cool bugs. (or as halvar would say "deep sea fish are good eatin'!")

Well, it gave me a pretty girl picture and a plethora of garbage, all followed by "Hello cruel world." But no crash. It really pays to NOT use IE. $.02 Moe -------------------- Dave Aitel wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The below email (not from me) is an interesting and weird bug and I > felt it merited some notice. > > - -dave > > _____________________________________________________________________________ > > From: Michael Zalewski - lcamtuf@xxxxxxxxxxxx > > Good morning, > > This might not come as a surprise, but there appears to be a *very* > interesting and apparently very much exploitable overflow in Microsoft > Internet Explorer (mshtml.dll). > > This vulnerability can be triggered by specifying more than a couple > thousand script action handlers (such as onLoad, onMouseMove, etc) for any > single HTML tag. Due to a programming error, MSIE will then attempt to > write memory array out of bounds, at an offset corresponding to the ID of > the script action handler multiplied by 4 (due to 32-bit address clipping, > the result is a small positive integer). > > The list of IDs can be found on the Web, and is as follows (values in > parentheses = resulting offsets): > > onhelp = 0x8001177d (+0x45df4) > onclick = 0x80011778 (+0x45de0) > ondblclick = 0x80011779 (+0x45de4) > onkeyup = 0x80011776 (+0x45dd8) > onkeydown = 0x80011775 (+0x45dd4) > onkeypress = 0x80011777 (+0x45ddc) > onmouseup = 0x80011773 (+0x45dcc) > onmousedown = 0x80011772 (+0x45dc8) > onmousemove = 0x80011774 (+0x45dd0) > onmouseout = 0x80011771 (+0x45dc4) > onmouseover = 0x80011770 (+0x45dc0) > onreadystatechange = 0x80011789 (+0x45e24) > onafterupdate = 0x80011786 (+0x45e18) > onrowexit = 0x80011782 (+0x45e08) > onrowenter = 0x80011783 (+0x45e0c) > ondragstart = 0x80011793 (+0x45e4c) > onselectstart = 0x80011795 (+0x45e54) > > What happens next depends on the structure of the page in which the > malicious tag is embedded, as well as previously visited page and > previously initialized extensions (all these factors can be controlled by > the attacker). > > When the offending page contains no additional elements, and the user is > not redirected from elsewhere, the browser will typically crash > immediately, because there is no allocated memory at the resulting offset. > In all other cases, crashes will typically occur later, due to attempted > use of unrelated but corrupted in-memory buffers -for example, when the > user attempts to leave or reload the page. Another good example is coming > from a page that contains Macromedia Flash - this usually causes the Flash > plugin itself to choke on corrupted memory on cleanup. > > For non-believers, there's a short but fiery demonstration page available > at http://lcamtuf.coredump.cx/iedie.html (yes, it will probably crash your > browser). > > Tested on MSIE 6.0.2900.2180.xpsp2.040806-1825 on Windows XP SP2. As far > as I can tell, other browser makes (Firefox, Opera) are not susceptible to > this attack. > > I eagerly await due reprimend from Microsoft for not disclosing this > vulnerability in a manner that benefits them most, not passing start, not > collecting $200 (from iDefense?). > > Regards, > /mz > http://lcamtuf.coredump.cx/silence/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFEGes4B8JNm+PA+iURAsZsAJ0XGy+wgQVYxD1THdhkuTpw7pLnQgCaA03g > gBd30LhoXNtpVYFXWZNYzko= > =f+Yl > -----END PGP SIGNATURE-----

Next Message by Thread: click to view message preview

Generically Determining the Prescence of Virtual Machines

At OffensiveComputing we were looking at ways to detect virtual machines and had found and discarded many unsophisticated methods such as looking for VMWare Tools running as a service or VMWare related registy keys, etc. Then we discovered Joanna Rutkowska's very interesting "Redpill" method. This was an eye opening work for us. After spending a little time playing with it we realized it wasn't fool proof on multiprocessor systems and so we decided to research the problems and possible ways to improve on the method. We discovered and implemented an improved method which is presented in the this paper. Check http://www.offensivecomputing.net for the paper.V.