Subject: Re: Security Issue that prolly should be addressed in some mannor

From: Gregory A Lundberg <[email-masked]>
Date: Mon, 8 Feb 1999 15:13:53 -0500 (EST)

On Sat, 8 Nov 1997, Bret McDanel wrote:

> Date: Sat, 8 Nov 1997 14:03:02 -0500
> From: Bret McDanel <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Security Issue that prolly should be addressed in some mannor
> 
> ---Reply on mail from Gregory A Lundberg about Security Issue that prolly should be addressed in some mannor
> 
> > The only thing close to a workable solution I see on the nai.com site is
> > the following quote:
> > 
> >     The problem with these auxiliary connections is that the existing
> >     FTP protocol lacks any method of assuring that the client or
> >     server which initiates the connection is really the one attached
> >     to the associated control connection.
> > 
> > In other words, they don't have one which will work.  Their only proposal
> > would require a change to existing clients and servers which is unlikely
> > to be widely deployed anytime soon.
> > 
> yes but since the accept() call takes an argument (#2) of a struct
> sockaddr, and fills this with the information of the client that is
> connecting, then it is quite possible for the server to limit the
> connections (PASV) to the IP that asked for it..  This will minimize the
> risk (and I thought it was mentioned on one of those 2 sites, if not it is
> now mentioned here)..

Unfortunately, I have evidence from watching this problem on my own ftp
site that such a fix would, by violating the RFC, break a number of
firewall/proxy products which use a randomly-chosen source IP for the data
connections.  I will grant that for PASV mode it is dubious whether this
does anything for the security of the client site, but for PORT mode it
has obvious advantages.

I have a scheme in hand to enforce the use of a randomly chosen PASV port.
I have not yet implemented it because, until your boast today (see below),
there were no known occuances of this in the wild and because the solution
which was submitted to me was not simple enough to be easily used by a
wide range of FTP site admins.

> > It is important to realize what is said at inforwar.com:
> > 
> >     The ability for this attack to be performed is not 100%
> >     guaranteed. The higher the volume of traffic an FTP server sees,
> >     the higher the potential for a successful attack. This attack has
> >     not yet been observed in the wild.
> > 
> yes but I wrote a program and released it last week..  So it is out
> there..  My program only would dump 1 connection, and would exit after
> that one connection, the unreleased version (woo this is really hard)
> loops forever logging to files, and changes the port range that it scans
> so that it keeps up with the new ports that the server issues..
> 
> As for it not being 100% that is correct its a race condition where the
> client (maybe unknown to the attacker) issues the PASV command, and then
> connects..  If you get in there between that time then you get the data
> channel..  My program against ftp.cdrom.com worked quite well (dont know
> how well on a percentage basis I didnt to a 'SITE STATS' to see how many
> transfers or whatever was done) it got a hit every second or two..  This
> is quite high (I knew that ftp.cdrom.com would have a lot of activity so
> it seemed a good 'final test' area).. 

Testing in-lab is one thing; I certainly hope you're simply boasting about
attacking ftp.cdrom.com or that you had their permission to do so.  Even
if you designed the test to ensure their servers were not compromised, it
shows an appauling lack of professionalism on your part to have used them
unwittingly to test your attack.

And as for 'released' I hope you mean 'gave my boss a copy' and not
'published to the world'.  Again, in-lab research is all well and good but
a security professional has NO business making his attacks publicly
available until AFTER ensuring the effected clients and servers have had
ample opportunity to correct the problem.  If you feel your attack would
not be accepted by the maintainers of the clients and servers, the proper
channel would be to have it peer-reviewed by a trusted third-party (such
as CERT or AUSCERT) or taking up the matter with the appropriate IETF
Working Group rather than throwing it out for the script kids to play
with.

> > They point out:
> > 
> >     Solving the problem requires careful thought. Server programmers
> >     can program a server to identify the client address associated
> >     with the control port and only allow data port connections from
> >     the client address, however this server would not be RFC compliant.
> > 
> yup ok it did say that..  *THAT* much would improve the security greatly
> (however not completly close the hole)..

No, it does not because if the attacker is on the same machine (as is
common on many campus) the server has no way of knowing the connection
should not be honored.  This is the reason that, as much as I'd like to
add this test, I haven't.  It doesn't solve the problem from the
highest-risk sites: universities and disgruntled employees on 'intranets'.

> > The only currently viable solution is RFC2228 to which infowar.com rightly
> > points out:
> > 
> >     Through the use of a secured data channel, the Pizza Thief threat
> >     is reduced to a simple denial of service attack.
> > 
> yeah, mostly anonying as it wouldnt be complete, and it would leave a
> trail to the box/network that was trying to do this..  There would be much
> better DoS attacks than this..

Deployment of RFC2228-capable clients is sadly lagging.

For those concerned immedeately; BeroFTPD includes some support for
RFC2228 (on Kerberos).  The base, beta-18 daemon does not and I have no
plans to add RFC2228 to the VR series.  If you run Kerberos, can deploy
RFC2228-enabled ftp clients, and are concerned about this attack, I
recommend checking into upgrading to BeroFTPD.

-- 

Gregory A Lundberg		Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: Chad Price <[email-masked]>
Date: Mon, 08 Feb 1999 14:40:54 -0600

>On Sat, 8 Nov 1997, Bret McDanel wrote:
[SNIP]
>Working Group rather than throwing it out for the script kids to play

Since I posted some questions about getting the Bero version of WU-FTPd
running at my site, there has been a noticable increase in anonymous
connctions from places which normally should have no reason to login to my
site - I have nothing of interest to them.  I suspect some of these
connections are simply to see if I have overlooked something trivial,
others would appear to be probes for places to hack into.

Posters to this list should be aware that posting their address to a list
like this and enumerating problems is likely to provoke unwanted connections.  

Chad

Chad Price
Systems Manager
University of Nebraska Medical Center
600 S 42nd St
Omaha, NE 68506-6495
[email-masked]
(402) 559-9527 
(402) 559-4077 (FAX)

---

From: Gregory A Lundberg <[email-masked]>
Date: Mon, 8 Feb 1999 16:01:47 -0500 (EST)

On Mon, 8 Feb 1999, Chad Price wrote:

> Since I posted some questions about getting the Bero version of
> WU-FTPd running at my site, there has been a noticable increase in
> anonymous connctions from places which normally should have no reason
> to login to my site - I have nothing of interest to them.  I suspect
> some of these connections are simply to see if I have overlooked
> something trivial, others would appear to be probes for places to hack
> into.
> 
> Posters to this list should be aware that posting their address to a
> list like this and enumerating problems is likely to provoke unwanted
> connections.

My experience is somewhat different.  I have FTP servers running on
test-bed machines, some on the vr.net domain, some not.  I have noticed
that even without publishing the domain where an FTP site is, there is a
surprising amount of anonymous traffic.  So much so, that I was foreced to
move my test files (nothing important, just copies of stuff from my public
ftp site) into the private area so people would not be downloading things
from the wrong servers.

My point is that, once on the internet, people will find the site.
Security through obscurity fails.  Period.  If you don't want it freely
distributed don't put it on the 'net!

--

---

From: Bret McDanel <[email-masked]>
Date: Sat, 8 Nov 1997 17:06:24 -0500

>>unwittingly to test your attack.
[ To Greg Lundberg ]
you should have known if I was boasting (as you put it) or not BEFORE you
called my boss and tried to get me fired..

And it shows a lack of professionalism in your judgement to have called my
boss on the phone making threats against me and trying to get me fired for 
releasing the program..  But hey that must have been a lot easier than
actually fixing a multiple year old problem..

>>Working Group rather than throwing it out for the script kids to play
No, I posted to NTSEC ([email-masked]) and bugtraq
([email-masked]) in responce to an advisory (from www.infowar.com,
advisory #01) that was posted to NTESC..  It appears that ballista has
scanned for this type of problem for a LONG time, and it is known to many
for a LONG time (Aleph One (moderator of bugtraq) refused the program on
the basis that its "very, very old", and it appears that it is indeed old,
thus giving MORE than enough time to fix it, if a fix was disired)..

Earlier today when I tried to say that it should be addressed here (all
ftp servers still seem vunerable, havent tried it against Bero, however)
you seemed to think that it wasnt that big of a problem..  

The code is trivial, basically its a port scanner (how many of those are
out there already) that records data from the port not just the fact that
there is a connection (ohh that is really hard to do)..  If you just run a
portscanner against a busy FTP site, then it will be a DoS to this, yet no
one is complaining about people writing port scanners becuase they can DoS
ftpd (and the RFC doesnt say that ftpd should be DoSed by a portscanner so
that is indeed a coding problem with the server)..

> others would appear to be probes for places to hack into.
[ to chris ]
Yeah, that also happens for some commercial software, I have heard that
people have subscribed to lists that talk about certain peices of software
and when someone says 'I have that' they attack that site..  

I dont see why its that different than shouting in a crowded room that you
have things like a VCR or TV or ... I dont know of anyone that would goto
the mall and yell that they have a really nice big screen TV at home AND
give out their address, but people do it a lot from known names and talk
about software that they run (sometimes giving out OS versions, daemons
installed, etc)..

> like this and enumerating problems is likely to provoke unwanted connections.  
This and any other list..

Now for the patch:
I was informed that Greg Lundberg refused to work with me to fix this, so
I did something on my own, and not being familiar with the way that
patches are packaged up I did it my own way..  It is really small, and
makes this only into a DoS attack for a lot of sites (rather than DoS and
data theft) (can be fixed if more time and effort was put into it, however 
I dont care anymore since Greg called my boss, mentioned something about
the FBI and basically threatned my job earlier today I have lost all 
interest in helping fix wu-ftpd..

This should hold people over until Greg finally releases his 'random' PASV
port selection routine (as he indicated he has been working on)..  Again,
it will prevent data theft if the attacker isnt on the same system as the
real client, but it will prevent the real client from getting data for
that request (ie they have to request it again)..

In some situations it is possible that a person can get the data, however
the server attack only works for PASV connections.  This means that since
most shell machine ftp clients dont use PASV, and netscape/explorer (who
always use PASV) arent typically run on shell machines for FTP at great
regularity, the total ammount of theft is limited.  

Sites that implement NAT where all outgoing connections are the same IP
are still vunerable but only for connections from that site in the first
place..  

There doesnt seem to be a really _quick_ and _easy_ way to make ftpd accept
more than one connection on the same port if the IPs dont match.  If you
check your syslog messages and dont see a log entry like the one below
(that was already in the code) then odds are applying this wont affect
you, just prevent future data interception.

In src/ftpd.c at line 2502 I made it look like:
        if (strcmp(dataaddr, remoteaddr) != 0) {
        /*
         * This will log when data connection comes from an address different
         * than the control connection.
         */
            syslog(LOG_NOTICE, "%s of %s [%s]: data connect from %s for %s%s",
                anonymous ? guestpw : pw->pw_name, remotehost, remoteaddr,
                dataaddr, name, sizebuf);
#ifdef STRICT_DATA
            reply(500, "Can't build data connection");
            close(pdata);
            return(NULL);
#endif
        }

In config.h (at the top level not in src) I appended at the end:
/*
 * STRICT_DATA
 * Define this if you want the IP for the control connection and the 
 * data connection to be the same (limits some type of data theft)
 */
#define STRICT_DATA

-- 
Bret McDanel                                    http://www.rehost.com
Realistic Technologies, Inc.                             973-514-1144

     These opinions are mine, and may not be the same as my employer

---

From: Gregory A Lundberg <[email-masked]>
Date: Mon, 8 Feb 1999 17:50:06 -0500 (EST)

On Sat, 8 Nov 1997, Bret McDanel wrote:

> you should have known if I was boasting (as you put it) or not BEFORE
> you called my boss and tried to get me fired..

I called you boss because you appear to have committed a felony and felt
he would be able to handle it more quickly and more efficiently than the
FBI or cdrom.com's laywers.  I did not, however, attempt to get you fired.  
In fact, I told him I would be willing to work with you on this issue once
the issue of your credentials had been established.

If my position on this is unacceptable to you, I can contact cdrom.com and
the FBI and they can explain things to you in more forcefull language.

I had hoped, btw, to keep this portion of this incident private between
the three of us.

> And it shows a lack of professionalism in your judgement to have
> called my boss on the phone making threats against me and trying to
> get me fired for releasing the program..  But hey that must have been
> a lot easier than actually fixing a multiple year old problem..
>

> ([email-masked]) in responce to an advisory (from
> www.infowar.com, advisory #01) that was posted to NTESC..  It appears
> that ballista has scanned for this type of problem for a LONG time,
> and it is known to many for a LONG time (Aleph One (moderator of
> bugtraq) refused the program on the basis that its "very, very old",
> and it appears that it is indeed old, thus giving MORE than enough
> time to fix it, if a fix was disired)..
> 
> Earlier today when I tried to say that it should be addressed here
> (all ftp servers still seem vunerable, havent tried it against Bero,
> however) you seemed to think that it wasnt that big of a problem..
> 
> The code is trivial, basically its a port scanner (how many of those
> are out there already) that records data from the port not just the
> fact that there is a connection (ohh that is really hard to do)..  If
> you just run a portscanner against a busy FTP site, then it will be a
> DoS to this, yet no one is complaining about people writing port
> scanners becuase they can DoS ftpd (and the RFC doesnt say that ftpd
> should be DoSed by a portscanner so that is indeed a coding problem
> with the server)..

Of course the code is trivial.  My first response to your posting was to
ensure the followers of this list that the problem was old and had never
been noted in the wild.  Sure, they could do that by reading your links,
but I felt a posting would be more effective.

Believe me, I have been pondering this problem for many months now
(aproximately the same period I have been maintaining a version of
wu-ftpd).  For me, this is not an old problem.  It is, however, not as
high a priority as more direct assaults which have been brought to my
attention and which might potentially yield root privileges on the target
machine.  Nor is it as high a priority as improving the admin's ability to
properly configure and manage his server.

I placed a low priority on the problem because it had never been seen in
the wild.  In your misguided zealousness to glean some fame for yourself,
you have released ready-made code for even the lowliest script kid to play
with.  And trust me, play with it they will.

Now, those of us who maintain FTP servers, not just wu-ftpd, but *ALL*
servers, must rush about, patching, attempting to limit the damage you
have caused.  Next time, as I'm quite sure your boss has impressed upon
you, think before you act.

> I was informed that Greg Lundberg refused to work with me to fix this,

I told him, via private email, that I was satisified you were actually
working on network security and th I no longer felt I needed him in the
loop unless he wanted to remain there.

> so I did something on my own, and not being familiar with the way that
> makes this only into a DoS attack for a lot of sites (rather than DoS
> and data theft) (can be fixed if more time and effort was put into it,
> however I dont care anymore since Greg called my boss, mentioned
> something about the FBI and basically threatned my job earlier today I
> have lost all interest in helping fix wu-ftpd..
> 
> This should hold people over until Greg finally releases his 'random'
> PASV port selection routine (as he indicated he has been working on)..  
> Again, it will prevent data theft if the attacker isnt on the same
> system as the real client, but it will prevent the real client from
> getting data for that request (ie they have to request it again)..
> 
> In some situations it is possible that a person can get the data,
> however the server attack only works for PASV connections.  This means
> that since most shell machine ftp clients dont use PASV, and
> netscape/explorer (who always use PASV) arent typically run on shell
> machines for FTP at great regularity, the total ammount of theft is
> limited.
> 
> Sites that implement NAT where all outgoing connections are the same
> IP are still vunerable but only for connections from that site in the
> first place..
> 
> There doesnt seem to be a really _quick_ and _easy_ way to make ftpd
> accept more than one connection on the same port if the IPs dont
> match.  If you check your syslog messages and dont see a log entry
> like the one below (that was already in the code) then odds are
> applying this wont affect you, just prevent future data interception.
> 

This patch is a quick fix.  it will not protect your site if the client is
on a shared-access machine where the race-attacker and the innocent-client
share the same IP address as is the case on many campus and with not a few
firewall/proxies.  Since it is highly likely that such will be the case,
this patch serves more to show how a quick-fix pushed out without due
thought might give a false sense of security.

-- 

Gregory A Lundberg		Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: Chad Price <[email-masked]>
Date: Mon, 08 Feb 1999 17:00:11 -0600

OK - now that we've got people thoroughly pissed of and a flame war
started, lets consider: 

Bret seems to have found a problem and injudiciously posted that he tried
an attack against a commercial site.  We don't know what actually happened.

Greg took exception and apparently without asking Bret seems to have got on
the phone to Bret's boss.

I think both parties made mistakes here and some over-reaction occurred.
Maybe the fix should be incorporated and the whole thing dropped.

Please guys, stop and think before you post and react.  I've seen flame
wars ruin enough lists and newsgroups in my time.  I don't want to see that
happen to this group, which supports the most responsive and useful ftp
server available.

Chad

Chad Price
Systems Manager

---

From: Bret McDanel <[email-masked]>
Date: Tue, 9 Feb 1999 10:08:26 -0500

---Reply on mail from Gregory A Lundberg about Patch - Re: Security Issue that prolly should be addressed insome mannor

> the issue of your credentials had been established.
well you said after you had finished everything you would then inform me,
to quote: "Once I have the code in place, I propose notifying Bret"

I never said that I committed a felony, you assumed that..  I never said
that the connections that I hijacked werent mine (or those of a friends)..
It would be trivial to check this if I telnet to the ftp server issue the
PASV command (and I like to also at that time issue a LIST command) and
then telnet in from a DIFFERENT machine to see if it is vunerable..  That
only takes a couple seconds to do (espically with a program that connects
and spits out the port on its own so I dont have to convert the 2 number
port into a single number)..

I think this has to do with the fact that I said I released a program that
would connect to an ftp server and pull off data (you refused to admit
there was a problem until I said that, at which time you went ape shit and
called my boss, emailed him saying "What concerns me more is his claim to
have 'released' the attack." if that was your major concern then I can see
how your ego would be bruised and you would call up and threaten the FBI
on my boss if he didnt filter all my email and stuff..

> I had hoped, btw, to keep this portion of this incident private between
Why so that people dont see that if problems are found in ftpd they should
NOT report them for fear that you will call their employer and threaten
them?? 

> but I felt a posting would be more effective.
Oh I thought it was to say that hte problem wasnt that real cause it hadnt
been seen in the wild..  How many people really knew that first, there was
a problem, and second what to look for if someone was doing this??

> with.  And trust me, play with it they will.
I only mentioned that AFTER you refused to admit the problem..  How is
that seeking fame??  I also didnt release it in my name, so again how is
that seeking fame??  Had you just said 'Gee I know I am working on fixing
that' instead of trying to deny it in the first place I wouldnt have said
anything..

> you, think before you act.
I caused??  this is a multi year old problem that has not been fixed,
there were other people talking about this specific thing BEFORE I wrote
my program..  I did not write the crappy code into ftpd, I didnt cause the
problem, the problem was always there..  You lack in programming skills
should not be blamed on me, if you cant fix problems that you are aware
of, ask for help, if you cant ask for help dont blame others for the
problem being there (just to clairfy, the problem was there long before I
wrote this trivial program (which is barely more than a port scanner)) 

You admitted to knowledge of this problem, and refused to fix it until AFTER
it was released..  To think that people dont have such simple programs is
insane..  I actually think in this case it was a good thing that it was
released, how much longer were you going to wait (even after an advisory
released feb 01, even after nai's ballista program scans for this specific
thing, etc) to patch any of the distributions (even the one(s) that you
are resonsible for)???