Bug 589190 (CVE-2010-3181)

Binary planting potential in nsMIMEInfoWin::LaunchWithFile

RESOLVED FIXED in mozilla2.0b5

Status

()

Core
Document Navigation
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Ehsan, Assigned: Ehsan)

Tracking

Trunk
mozilla2.0b5
x86
All
Points:
---

Firefox Tracking Flags

(blocking2.0 final+, blocking1.9.2 .11+, status1.9.2 .11-fixed, blocking1.9.1 .14+, status1.9.1 .14-fixed)

Details

(Whiteboard: [sg:critical?] [qa-ntd-191] [qa-ntd-192])

Attachments

(1 attachment, 1 obsolete attachment)

This code <http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/win/nsMIMEInfoWin.cpp#142> needs to use an absolute path.
Created attachment 467835 [details] [diff] [review]
Patch (v1)
Attachment #467835 - Flags: review?(benjamin)

Updated

7 years ago
OS: Windows XP → All
Whiteboard: [sg:critical?]

Updated

7 years ago
Whiteboard: [sg:critical?] → [sg:critical?][critsmash:patch]
Comment on attachment 467835 [details] [diff] [review]
Patch (v1)

Please make rundll32.exe a #define so that the sizeof and the lstrcat don't accidentally end up out of sync. As noted on IRC, I'd prefer that we had a helper function to do this (that we could share to fix LoadLibrary callsites also), but that is not essential.
Attachment #467835 - Flags: review?(benjamin) → review+
Created attachment 469115 [details] [diff] [review]
Patch (v1.1)

(In reply to comment #2)
> Comment on attachment 467835 [details] [diff] [review]
> Patch (v1)
> 
> Please make rundll32.exe a #define so that the sizeof and the lstrcat don't
> accidentally end up out of sync.

Done.

> As noted on IRC, I'd prefer that we had a
> helper function to do this (that we could share to fix LoadLibrary callsites
> also), but that is not essential.

I'll do that if we decide to patch all the callsites in bug 286382.
Attachment #467835 - Attachment is obsolete: true
Attachment #469115 - Flags: approval2.0?
blocking1.9.1: --- → ?
blocking1.9.2: --- → ?
blocking2.0: --- → ?

Updated

7 years ago
Attachment #469115 - Flags: approval2.0? → approval2.0+
http://hg.mozilla.org/mozilla-central/rev/e94ae58bfd42
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b5
Attachment #469115 - Flags: approval1.9.2.10?
Attachment #469115 - Flags: approval1.9.1.13?
Whiteboard: [sg:critical?][critsmash:patch] → [sg:critical?]
Is there really a risk that rundll32.dll won't exist in the windows system directory? If it's always in the path before the current directory there's no "dll planting" risk.
(In reply to comment #5)
> Is there really a risk that rundll32.dll won't exist in the windows system
> directory? If it's always in the path before the current directory there's no
> "dll planting" risk.

The order in which Windows tries to load executables from is even worse than DLLs:

    The directory from which the application loaded.
    The current directory for the parent process.
    The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory.
    The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System.
    The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
    The directories that are listed in the PATH environment variable. Note that this function does not search the per-application path specified by the App Paths registry key. To include this per-application path in the search sequence, use the ShellExecute function.

(From http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx)

Therefore, if rundll32.exe is present in the current directory, it will be picked up by default no matter whether one exists in the system directory).

(BTW, rundll32 is not a DLL, it's an executable program.)
blocking1.9.1: ? → .13+
blocking1.9.2: ? → .10+
status1.9.1: --- → wanted
status1.9.2: --- → wanted
Comment on attachment 469115 [details] [diff] [review]
Patch (v1.1)

Approved for 1.9.2.10 and 1.9.1.13, a=dveditz for release-drivers
Attachment #469115 - Flags: approval1.9.2.10?
Attachment #469115 - Flags: approval1.9.2.10+
Attachment #469115 - Flags: approval1.9.1.13?
Attachment #469115 - Flags: approval1.9.1.13+
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/4113b60ec4b6
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/c14b8ca2bba0
status1.9.1: wanted → .13-fixed
status1.9.2: wanted → .10-fixed
Other than code inspection, is there anything for QA to do in regards to verification for this bug on the branches?
(In reply to comment #9)
> Other than code inspection, is there anything for QA to do in regards to
> verification for this bug on the branches?

I'm afraid not.
blocking2.0: ? → final+
All right. Thanks.
Whiteboard: [sg:critical?] → [sg:critical?] [qa-ntd-191] [qa-ntd-192]
Alias: CVE-2010-3181
Group: core-security
You need to log in before you can comment on or make changes to this bug.