[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: Backport of the integer overflow in the brk system call

Russell Coker wrote:
> On Mon, 8 Dec 2003 13:16, Patrick Ouellette <pouelle@debian.org> wrote:
> > Instead of a smartcard/token/whatever physical device, this incident
> > could possibly have been thwarted by requiring developers to
> > pre-register their machine with the project (using ssh host key for
> > example).  The attacker would have the user's account information,
> > but project machines would have refused access since the host id did
> > not match the user's registered hosts.  Then the project machine
> > could have alerted both the project's admin team and the owner of the
> > compromised account. 
> One problem with this is developer's machines that are on dial-up
> Internet connections.  In the case of such machines you can verify the
> host key but not the IP address.

You cannot verify the IP address *exactly*, but you can verify whether the IP address lies within a range.  Dial-up users could at least register a certain address range, so as to vastly mitigate the attack risk.  Apart from that, as soon as the use of IPv6 broadens, dynamically assigned IP addresses will diminish.

> But this still leaves the issue of how to deal with dial-up machines. 
> Even if we restrict connections to a single ISP as often dial-up
> machines are not used with multiple machines, this still isn't
> necessarily much good, some dial-up ISPs have >50,000 IP addresses.

Still, IP address (even if it's a range, not a single address) verification vastly mitigates the attack risk.

> Finally, if the attacker can compromise the machine and the machine is
> online (EG permanently connected machines) there's no good options.

What's more secure, "no good options", or "no good options" plus IP address verification, even if range-based?  Some attack vectors one will never be able to protect against, but it still makes sense to protect against other vectors, doesn't it?

Reply to: