6 ms·

If anyone is wondering how the attack works, here's a guess: file://../../dev/tcp/74.125.225.19/80 That would also explain why it works on 'nix but not window

If anyone is wondering how the attack works, here's a guess: file://../../dev/tcp/74.125.225.19/80 That would also explain why it works on 'nix but not windows. (This is probably mistaken, but the attack might be something along those lines.) Hmm... Anyone have a link to the hotfix diff? We could just look rather than guess.

JoshTriplett 9y ago
/dev/tcp doesn't exist on the filesystem, only in bash, and only if enabled; some distributions like Debian disable it.
- gnu8 9y ago
  I can imagine why that would be useful, but that seems like a fundamentally misguided feature. The shell is a key partner in the Unix philosophy of small programs that do a particular thing. The maintainers of bash should have known better than to add this. What does /dev/tcp add to bash, other than security vulnerabilities, that couldn't be better accomplished with wget, curl, netcat, or similar programs external to bash?
- sillysaurus3 9y ago
  Yeah, it was a wild guess. I just looked over all the new bug tracker entries in Tor since Oct 28th, but none of them seem particularly critical. Our best bet would be to look at Firefox's commit history since the 28th. One crafty way to determine the exploit would be to bindiff the hotfix'd firefox binary vs the previous release and examine the diffs in a disassembler to see what code changed. Non-deterministic builds make that tricky, but it's a neat technique to be aware of.
  - qeternity 9y ago
    Isn't this pretty standard practice?
    - sillysaurus3 9y ago
      It is. But no one has posted details of the exploit yet. I was hoping someone would go find that out. (I can't right now else I would.)
phire 9y ago
So... file://example.com/path/to/file and/or file:////example.com/path/to/file are valid file URIs which might cause an implementation to access the remote host example.com via smb/cifs, nfs or ncp protocols. Source: https://tools.ietf.org/id/draft-kerwin-file-scheme-07.html https://tools.ietf.org/id/draft-kerwin-file-scheme-07.html
- sillysaurus3 9y ago
  Ah yes, thank you. It really is that simple: 6.6. Applications/Protocols That Use This URI Scheme Name Web browsers: Firefox Note: Firefox has a unique interpretation of RFC 1738 (See: Bugzilla#107540), which affects UNC paths. See Bugzilla#107540 from 16 years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=107540 https://bugzilla.mozilla.org/show_bug.cgi?id=107540 --- If url format is file:////servername/dir/file.html Mozilla does not navigate to the link. This format works in IE5. Reproducible: Always Steps to Reproduce: 1. Put url in page - format file:////servername/dir/file.html 2. Try to navigage to link 3. Actual Results: Nothing Expected Results: It should have opened link --- reply from Neil Becker: We have many links on our internal company website using the file:////server/a/b/c/ convention to access files on our network drives. mozilla seems to want file:///// (5 slashes) but IE and even the old netscape accept 4 slashes. It seems that to access a local file, if you write file://D:/qtdocs/classes.html for instance, (2 slashes) mozilla automatically changes it to 3. so... when a link specifies FOUR slashes for a UNC name, it would make sense if mozilla would either expand it to FIVE slashes and check it like that, or accept the 4 slashes. In our company's opinion, this is a bug, not a feature... It's a bug that'll cause us to not use mozilla and instead use IE or another browser than can do the file:////server/a/b/c links. it doesn't seem to be hard to fix - if there's four slashes in the link, change it to 5 and try it. just like you change 2 slashes into 3 for a local hard drive file. cmon! I would really like to see this bugfix in the mozilla 1.0 release. this is NOT a duplicate bug (i checked the others that are claimed to be a dupe and its not). so would someone please fix this????? thanks.

JoshTriplett 9y ago

/dev/tcp doesn't exist on the filesystem, only in bash, and only if enabled; some distributions like Debian disable it.

gnu8 9y ago
I can imagine why that would be useful, but that seems like a fundamentally misguided feature. The shell is a key partner in the Unix philosophy of small programs that do a particular thing. The maintainers of bash should have known better than to add this. What does /dev/tcp add to bash, other than security vulnerabilities, that couldn't be better accomplished with wget, curl, netcat, or similar programs external to bash?
sillysaurus3 9y ago
Yeah, it was a wild guess. I just looked over all the new bug tracker entries in Tor since Oct 28th, but none of them seem particularly critical. Our best bet would be to look at Firefox's commit history since the 28th. One crafty way to determine the exploit would be to bindiff the hotfix'd firefox binary vs the previous release and examine the diffs in a disassembler to see what code changed. Non-deterministic builds make that tricky, but it's a neat technique to be aware of.
- qeternity 9y ago
  Isn't this pretty standard practice?
  - sillysaurus3 9y ago
    It is. But no one has posted details of the exploit yet. I was hoping someone would go find that out. (I can't right now else I would.)

phire 9y ago

So... file://example.com/path/to/file and/or file:////example.com/path/to/file are valid file URIs which might cause an implementation to access the remote host example.com via smb/cifs, nfs or ncp protocols. Source: https://tools.ietf.org/id/draft-kerwin-file-scheme-07.html https://tools.ietf.org/id/draft-kerwin-file-scheme-07.html

sillysaurus3 9y ago
Ah yes, thank you. It really is that simple: 6.6. Applications/Protocols That Use This URI Scheme Name Web browsers: Firefox Note: Firefox has a unique interpretation of RFC 1738 (See: Bugzilla#107540), which affects UNC paths. See Bugzilla#107540 from 16 years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=107540 https://bugzilla.mozilla.org/show_bug.cgi?id=107540 --- If url format is file:////servername/dir/file.html Mozilla does not navigate to the link. This format works in IE5. Reproducible: Always Steps to Reproduce: 1. Put url in page - format file:////servername/dir/file.html 2. Try to navigage to link 3. Actual Results: Nothing Expected Results: It should have opened link --- reply from Neil Becker: We have many links on our internal company website using the file:////server/a/b/c/ convention to access files on our network drives. mozilla seems to want file:///// (5 slashes) but IE and even the old netscape accept 4 slashes. It seems that to access a local file, if you write file://D:/qtdocs/classes.html for instance, (2 slashes) mozilla automatically changes it to 3. so... when a link specifies FOUR slashes for a UNC name, it would make sense if mozilla would either expand it to FIVE slashes and check it like that, or accept the 4 slashes. In our company's opinion, this is a bug, not a feature... It's a bug that'll cause us to not use mozilla and instead use IE or another browser than can do the file:////server/a/b/c links. it doesn't seem to be hard to fix - if there's four slashes in the link, change it to 5 and try it. just like you change 2 slashes into 3 for a local hard drive file. cmon! I would really like to see this bugfix in the mozilla 1.0 release. this is NOT a duplicate bug (i checked the others that are claimed to be a dupe and its not). so would someone please fix this????? thanks.