Closed
Bug 1356668
Opened 8 years ago
Closed 6 years ago
Read and write beyond bounds in nsImageFromClipboard::InvertRows()
Categories
(Core :: Widget: Win32, defect, P4)
Tracking
()
RESOLVED
DUPLICATE
of bug 1501482
People
(Reporter: q1, Unassigned)
References
Details
(Keywords: reporter-external, sec-moderate, Whiteboard: tpi:+)
Attachments
(2 files)
nsImageFromClipboard::InvertRows() (widget\windows\nsImageClipboard.cpp) does not properly handle the case in which the input image contains < 1 row of data. In that case, line 282 (below) underflows, precipitating a read and write beyond bounds.
Attached is a POC that demonstrates this bug. In the POC, the bitmap dimensions are 32768 w * 43691 h * 24 bpp and |bv5SizeImage| == 0x8000, which means that |aSizeOfBuffer| == |bv5SizeImage| == 0x8000, and |aNumBytesPerRow| == 0x18000, so...
272: void
273: nsImageFromClipboard::InvertRows(unsigned char * aInitialBuffer, uint32_t aSizeOfBuffer, uint32_t aNumBytesPerRow)
274: {
275: if (!aNumBytesPerRow)
276: return;
277:
278: uint32_t numRows = aSizeOfBuffer / aNumBytesPerRow;
...line 278 calculates |numRows| == 0...
279: unsigned char * row = new unsigned char[aNumBytesPerRow];
280:
281: uint32_t currentRow = 0;
282: uint32_t lastRow = (numRows - 1) * aNumBytesPerRow;
...and |lastRow| becomes huge, causing the loop to read and write beyond bounds.
283: while (currentRow < lastRow)
284: {
285: // store the current row into a temporary buffer
286: memcpy(row, &aInitialBuffer[currentRow], aNumBytesPerRow);
287: memcpy(&aInitialBuffer[currentRow], &aInitialBuffer[lastRow], aNumBytesPerRow);
288: memcpy(&aInitialBuffer[lastRow], row, aNumBytesPerRow);
289: lastRow -= aNumBytesPerRow;
290: currentRow += aNumBytesPerRow;
291: }
292:
293: delete[] row;
294: }
Use the POC web page and code segment by creating a new Win32 (GUI-mode) project in Visual Studio. Replace the About() function with the POC code segment. Build the result. Start FF and attach the debugger to it, setting a BP on line 275, above. Load the POC web page. Now run the POC code and select help/about, then OK. Click on "Paste an image here!" and press ctrl/v. When the BP triggers, step through the code as above. Notice, in particular, that line 282 sets |lastRow| to |0xfffe8000|, and that the loop attempts to access/accesses memory (depending on your memory layout, the access might or might not be successful) far off the end of |aInitialBuffer|.
Comment 2•8 years ago
|
||
If I'm understanding the POC, an external program has created a clipboard object we don't handle correctly, a web page couldn't copy this to the clipboard itself? If so we'll call this sec-moderate because that would imply a malicious other program on your system (or an accidentally bad one).
Group: core-security → gfx-core-security
Keywords: sec-moderate
(In reply to Daniel Veditz [:dveditz] from comment #2)
> If I'm understanding the POC, an external program has created a clipboard
> object we don't handle correctly, a web page couldn't copy this to the
> clipboard itself? If so we'll call this sec-moderate because that would
> imply a malicious other program on your system (or an accidentally bad one).
This is correct, but note that the malicious (or bad) program could still create the defective clipboard object while running under a different account than FF, so this bug creates a cross-account vulnerability.
This is the kind of bug that might be exploited by an attacker targetting a particularly hard target: a person who gives network access only to specified programs, and who runs different programs under different (limited) accounts.
In this scenario, the attacker A persuades her target T to use (but not give network access to) apparently-useful program X. A instruments X to notice when T is connected to a network and hence when FF might be running. Occasionally X generates an appropriately-bad clipboard object, hoping the T will paste it into FF. (Perhaps A makes X "crash", then persuades T to copy and paste a "crash report" -- which really contains a bad clipboard object -- into FF). Then A uses this or other clipboard-handling bugs (e.g., anything spawned off https://bugzilla.mozilla.org/show_bug.cgi?id=1353927 ) to corrupt FF and use it as a RAT to spy on T.
This is a strange world...
Updated•8 years ago
|
Flags: sec-bounty?
Updated•8 years ago
|
Flags: sec-bounty? → sec-bounty+
Updated•8 years ago
|
Priority: -- → P4
Whiteboard: tpi:+
Updated•6 years ago
|
Group: gfx-core-security → layout-core-security
Updated•6 years ago
|
Group: layout-core-security → core-security-release
Comment 4•6 years ago
|
||
Bug 1501482 removed this code.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Updated•2 years ago
|
Group: core-security-release
Updated•6 months ago
|
Keywords: reporter-external
You need to log in
before you can comment on or make changes to this bug.
Description
•