Re: FreeBSD listen()

[vlad () SANDY RU (Vladimir Dubrovin)]

Hello Blue Boar,

06.11.1999 0:48, you wrote: FreeBSD listen();

B> Vladimir Dubrovin wrote:
> > According  to  RFC  959  (FILE TRANSFER PROTOCOL - STATUS:STANDARD) IP
> > address shouldn't be checked:

B> You probably didn't mean to imply this, but let me address it as if you
B> did.  First, thanks for pointing this out, it's very relevant.  Second, as
B> most folks here probably know, standards don't necessarily apply in
B> security situations.

B> On various firewall lists, etc.. I occasionally see a post where someone
B> makes a statement like "you can't do that, it violates standard x, and
B> breaks behavior y."  In my mind, security is all about breaking any
B> behavior you don't want to happen, per some policy, either written, or one
B> you make up on the spot.  This is irrespective of what the standards say.
B> This can be unfortunate, as most coders will tend to favor features over
B> security, and therefore tend to follow standards.  So, if the standard
B> includes risky features, so will the product.

Surely  you  can  do anything on your network and protect your network
against  any risk. For example you can only allow passive FTP for your
users  to  provide  more security (by the way - FreeBSD console client
doesn't  make  IP  checking...  According to RFC FTP model it may. And
this can be treated as security flow) . But software developers _must_
follow  RFC.  IP checking may be implemented this way in FTP server as
additional  configurable  feature.  But it's you who can turn it on or
turn  it  off.  And while RFC allows user to make data connection from
different IP, developers should take care about this option. They must
provide  additional security checking for this case - like making sure
that  exactly one connection is established. In any case this checking
is  necessary  -  otherwise unprivileged users can intersect data from
the  another  user on same IP (sic! not on the same machine while it's
possible to use FTP via any kind of proxy).

B> Ideally, the standard would be "fixed" and the products would have to
B> follow.  That's not going to happen with FTP.  (FTP should just be declared
B> obsolete, and blocked at the NAPs and MAEs, but that's a different rant.)

There  is  RFC  2228  (proposed  standard)  which specifies secure FTP
transactions,  including  password  and  data encryption. But a lot of
software doesn't support it :(

B> So, you probably pointed this out to explain where the behavior came from
B> (because it said so.)  I appreciate the info.  Silly me, I assumed like the
B> original poster that that sort of behavior is broken, a result of not
B> coding in a check.

B> The point here is that this creates a security problem that attackers can
B> take advantage of, and I assume we'd like a switch to turn it off with.

B>                                                         BB

 +=-=-=-=-=-=-=-=-=+
  |Vladimir Dubrovin|
  | Sandy Info, ISP |
  +=-=-=-=-=-=-=-=-=+