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)

52 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1501482

People

(Reporter: q1, Unassigned)

References

Details

(Keywords: reporter-external, sec-moderate, Whiteboard: tpi:+)

Attachments

(2 files)

Attached file bug_836_poc_1.cpp
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|.
Attached file bug_836_poc_1.htm
Blocks: 1353927
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...
Flags: sec-bounty?
Flags: sec-bounty? → sec-bounty+
Priority: -- → P4
Whiteboard: tpi:+
Group: gfx-core-security → layout-core-security
Group: layout-core-security → core-security-release

Bug 1501482 removed this code.

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: