Messages in this thread | | | Date | Thu, 13 Jan 2005 14:35:46 -0500 | From | John Richard Moser <> | Subject | Re: thoughts on kernel security issues |
| |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Norbert van Nobelen wrote: > On Thursday 13 January 2005 19:59, you wrote: >
[...]
>>You can't guarantee you can guess a password. You could for example >>write a pam module that mandates a 3 second delay on failed >>authentication for a user (it does it for the console currently; use 3 >>separate consoles and you can do the attack 3 times faster). Now you >>have to guess the password with one try every 3 seconds. > > > Already done, actually standard practice. This does not mean actually that you > can not guess a password, just that it will take longer (on average). > Luck and some knowledge about the system and people speeds up the process, so > the standard procedure if you really want to get into a system with a > password is to get information. > >
I'm pretty sure that you only get a 3 second delay on the specific console. I've mistyped my root password on tty1, and switched to tty2 to log in before the delay was up.
as a test, switch to vc/0 and enter 'root', then press enter. Type a bogus password.
Switch to vc/1, and enter 'root', then press enter. Type your real root password.
Go back to vc/0 and hit enter so you submit your false password, then immediately switch to vc/1 and hit enter.
You should get a bash shell and have enough time to switch to vc/0 and see it still waiting for a second or two, before returning "login incorrect."
Automating an attack on about 10 different ssh connections shouldn't be a problem. Just keep creating them.
> >>aA1# 96 possible values per character, 8 characters. 7.2139x10^15 >>combinations. It takes 686253404.7 years to go through all those at one >>every 3 seconds. You've got a good chance at half that. >> >>This isn't "hard," it's "infeasible." I think the idea is to make it so >>an attacker doesn't have to put lavish amounts of work into creating an >>exploit that reliably re-exploits a hole over and over again; but to >>make it so he can't make an exploit that actually works, unless it works >>only by rediculously remote chance. >> >> >>>So all security issues are about balancing cost vs gain. I'm convinced >>>that the gain from openness is higher than the cost. Others will >>>disagree. >> >>Yes. Nobody code audits your binaries. You need source code to do >>source code auditing. :) >> >> >>> Linus >>>- >>>To unsubscribe from this list: send the line "unsubscribe linux-kernel" >>>in the body of a message to majordomo@vger.kernel.org >>>More majordomo info at http://vger.kernel.org/majordomo-info.html >>>Please read the FAQ at http://www.tux.org/lkml/ > >
- -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB5s2QhDd4aOud5P8RAlwhAJ9G8SWcxq1HFCM58VIeEWJPevg9qgCeMpxt MHGB3N3TMy5n8MWnkUctqhM= =3mYn -----END PGP SIGNATURE----- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |