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: