lkml.org 
[lkml]   [2005]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.176 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site