Skip site navigation (1) Skip section navigation (2)

Re: Password requirement in windows installer

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Andrew Sullivan" <ajs(at)crankycanuck(dot)ca>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Password requirement in windows installer
Date: 2007-08-31 19:20:20
Message-ID: 877inb5x57.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
"Andrew Sullivan" <ajs(at)crankycanuck(dot)ca> writes:

> On Fri, Aug 31, 2007 at 07:07:40PM +0100, Gregory Stark wrote:
>> >
>> > It shouldn't be easy.  Ident uses TCP, which is rather harder to
>> > spoof.  
>> 
>> Say what? It's actually quite easy to spoof TCP. There are even command-line
>> tools to do it available in most Unix distributions.
>
> Sorry, I should have been more precise.  It's hard to spoof TCP
> easily and usefully.  It's trivial to spoof a TCP packet and send it,
> but because TCP depends on the handshake, 

Except note that ident is, like X, precisely the kind of protocol where the
handshake matters least. Since you all the relevant data comes early in the
message you can fire the SYN and the ACK (with the predicted sequence number)
with the first data packet off right away.

> there's a bunch of additional overhead that make the whole thing fragile:
> intermediate firewalls and such like tend to detect these things and prevent
> their continued use.

They may tend to but would you trust a system that depended entirely on a
firewall for security? Firewalls are not omniscient there are always cases
they don't cover. Better to use end-to-end secure protocols to begin with.

> (This is all in comparison with UDP, which is completely trivial to spoof.
> In the absence of BCP38, it's also almost impossible to detect, which is why
> the DNS is so vulnerable these days.)

Uhm, no DNS is vulnerable because it isn't authenticated. If you think any
other unauthenticated protocol is any "more secure" -- whatever that means --
on a public network then you're just depending on obscurity. I assure you that
no matter how narrow or difficult the exploit is there's someone out there
with the patience to run their attack script long enough to get through.

> I was thinking that, if your operating system is accepting packets
> from 127.0.0.1 on an external interface, you're already in a world of
> hurt.  

Well then lots of people are in a world of hurt. OSes only started adding
filters like this about 8-9 years ago and there are plenty of people running
Linux distributions older than this and other operating systems that are
slower to take up new ideas. In any case there are common misconfigurations
that defeat these kinds of filters too.

But yes, if I knew my OS had these filters in place I would be more or less
happy to run ident on 127.0.0.1. But I would be a lot happier running on Unix
domain sockets where it doesn't depend on an external daemon and ip filters --
just regular kernel credentials.

Just as an example, say you're running vmware or something like it and you're
bridging it on to your network. Will your ip filters will still kick in for
bridged packets? Are you 100.0% sure?

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Andrew SullivanDate: 2007-08-31 19:28:40
Subject: Re: Password requirement in windows installer
Previous:From: Tom LaneDate: 2007-08-31 19:18:03
Subject: Re: Attempt to stop dead instance can stop a random process?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group