There's a lot of warnings that pop up in my compiler for the eqemu code regarding comparisons between signed and unsigned integers. For this type of project, it's not a huge deal - but it is worth noting what kind of things can result from this problem.
Today on slashdot, there was an article showing exactly what can happen. The Microsoft code leaked last week showed a vulnerability in IE5 that allows a remote user to execute arbitrary code on the target system. The URL for reference is
http://www.securitytracker.com/alert...b/1009067.html.
Here's the important part:
Quote:
Code:
// Before we read the bits, seek to the correct location in the file
while (_bmfh.bfOffBits > (unsigned)cbRead)
{
BYTE abDummy[1024];
int cbSkip;
cbSkip = _bmfh.bfOffBits - cbRead;
if (cbSkip > 1024)
cbSkip = 1024;
if (!Read(abDummy, cbSkip))
goto Cleanup;
cbRead += cbSkip;
}
.. Rrrrriiiiggghhhttt. Way to go, using a signed integer for an
offset. Now all we have to do is create a BMP with bfOffBits > 2^31,
and we're in. cbSkip goes negative and the Read call clobbers the
stack with our data.
See attached for proof of concept. index.html has [img src=1.bmp]
where 1.bmp contains bfOffBits=0xEEEEEEEE plus 4k of 0x44332211.
Bring it up in IE5 (tested successfully on Win9 and get
EIP=0x44332211.
|
Morale of the story: Pay attention to what kind of datatypes you are using!