Hi,
Red Hat has released a new kernel today, that fixes several security issues.
I currently use 2.4.22-pre7, are those security issues solved in this kernel
too? Below are the descriptions from the errata:
> CAN-2003-0461: /proc/tty/driver/serial reveals the exact character counts
> for serial links. This could be used by a local attacker to infer password
> lengths and inter-keystroke timings during password entry.
> CAN-2003-0462: Paul Starzetz discovered a file read race condition existing
> in the execve() system call, which could cause a local crash.
> CAN-2003-0464: A recent change in the RPC code set the reuse flag on
> newly-created sockets. Olaf Kirch noticed that his could allow normal
> users to bind to UDP ports used for services such as nfsd.
> CAN-2003-0476: The execve system call in Linux 2.4.x records the file
> descriptor of the executable process in the file table of the calling
> process, allowing local users to gain read access to restricted file
> descriptors.
> CAN-2003-0501: The /proc filesystem in Linux allows local users to obtain
> sensitive information by opening various entries in /proc/self before
> executing a setuid program. This causes the program to fail to change the
> ownership and permissions of already opened entries.
> CAN-2003-0550: The STP protocol is known to have no security, which could
> allow attackers to alter the bridge topology. STP is now turned off by
> default.
> CAN-2003-0551: STP input processing was lax in its length checking, which
> could lead to a denial of service.
> CAN-2003-0552: Jerry Kreuscher discovered that the Forwarding table could
> be spoofed by sending forged packets with bogus source addresses the same
> as the local host.
Have fun,
Aschwin Marsman
--
aYniK Software Solutions all You need is Knowledge
P.O. box 134 NL-7600 AC Almelo - the Netherlands
[email protected] http://www.aYniK.com
On Monday 21 July 2003 22:40, Aschwin Marsman wrote:
Hi Aschwin,
> Red Hat has released a new kernel today, that fixes several security
> issues. I currently use 2.4.22-pre7, are those security issues solved in
> this kernel too?
no.
ciao, Marc
On Tue, 22 Jul 2003, Marc-Christian Petersen wrote:
> On Monday 21 July 2003 22:40, Aschwin Marsman wrote:
>
> Hi Aschwin,
Hi Marc,
> > Red Hat has released a new kernel today, that fixes several security
> > issues. I currently use 2.4.22-pre7, are those security issues solved in
> > this kernel too?
> no.
Thanks for your reply, I only hoped for another answer. I hope that these
security issues will be solved in 2.4.22-pre8.
> ciao, Marc
Have fun,
Aschwin Marsman
--
aYniK Software Solutions all You need is Knowledge
P.O. box 134 NL-7600 AC Almelo - the Netherlands
[email protected] http://www.aYniK.com
On Tuesday 22 July 2003 17:02, Aschwin Marsman wrote:
Hi Aschwin,
> > > Red Hat has released a new kernel today, that fixes several security
> > > issues. I currently use 2.4.22-pre7, are those security issues solved
> > > in this kernel too?
> > no.
> Thanks for your reply, I only hoped for another answer. I hope that these
> security issues will be solved in 2.4.22-pre8.
well, I hope that too ;)
I can send these patches for inclusion. Marcelo? Would you consider including
them?
ciao, Marc
On Tue, 22 Jul 2003, Marc-Christian Petersen wrote:
> On Tuesday 22 July 2003 17:02, Aschwin Marsman wrote:
>
> Hi Aschwin,
>
> > > > Red Hat has released a new kernel today, that fixes several security
> > > > issues. I currently use 2.4.22-pre7, are those security issues solved
> > > > in this kernel too?
> > > no.
> > Thanks for your reply, I only hoped for another answer. I hope that these
> > security issues will be solved in 2.4.22-pre8.
> well, I hope that too ;)
>
> I can send these patches for inclusion. Marcelo? Would you consider including
> them?
Yes, of course.
Please send them for _consideration_. ;)
Aschwin Marsman <[email protected]> wrote:
>
>> CAN-2003-0461: /proc/tty/driver/serial reveals the exact character counts
>> for serial links. This could be used by a local attacker to infer password
>> lengths and inter-keystroke timings during password entry.
What's the problem with exposing those counters? Are we going to restrict
access to /proc/interrupts and network interface counters too?
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Wed, 23 Jul 2003 19:56:47 +1000
Herbert Xu <[email protected]> wrote:
> Aschwin Marsman <[email protected]> wrote:
> >
> >> CAN-2003-0461: /proc/tty/driver/serial reveals the exact character counts
> >> for serial links. This could be used by a local attacker to infer password
> >> lengths and inter-keystroke timings during password entry.
>
> What's the problem with exposing those counters?
If I know your password is 7 characters I have a smaller
space of passwords to search to just brute-force it.
On Wed, Jul 23, 2003 at 03:35:05AM -0700, David S. Miller wrote:
> On Wed, 23 Jul 2003 19:56:47 +1000
> Herbert Xu <[email protected]> wrote:
>
> > Aschwin Marsman <[email protected]> wrote:
> > >
> > >> CAN-2003-0461: /proc/tty/driver/serial reveals the exact character counts
> > >> for serial links. This could be used by a local attacker to infer password
> > >> lengths and inter-keystroke timings during password entry.
> >
> > What's the problem with exposing those counters?
>
> If I know your password is 7 characters I have a smaller
> space of passwords to search to just brute-force it.
Yes but can't you do the same thing with /proc/interrupts or
/proc/net/dev? Why are we singling out the serial driver?
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Wed, Jul 23, 2003 at 03:35:05AM -0700, David S. Miller wrote:
>
> If I know your password is 7 characters I have a smaller
> space of passwords to search to just brute-force it.
It's much smaller if you didn't know that it was at most 7 characters
long. However, if you did know the upper bound, or you were just
brute forcing all passwords starting from 1 character, then the
difference is relatively minor. This is because
n + n^2 + n^3 + n^4 + n^5 + n^6
is much smaller than n^7 where n is something like 62 for a reasonable
password.
So if your password was broken using this method, then it's probably
too short anyway.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Wed, 23 Jul 2003 20:39:01 +1000
Herbert Xu <[email protected]> wrote:
> On Wed, Jul 23, 2003 at 03:35:05AM -0700, David S. Miller wrote:
> > On Wed, 23 Jul 2003 19:56:47 +1000
> > Herbert Xu <[email protected]> wrote:
> > If I know your password is 7 characters I have a smaller
> > space of passwords to search to just brute-force it.
>
> Yes but can't you do the same thing with /proc/interrupts or
> /proc/net/dev? Why are we singling out the serial driver?
With the serial procfs thing, we know exactly that it is
characters.
With interrupts and network device statistics, we cannot make
such assumptions making attacks using these facilities much
less likely to be feasible.
On Wed, 23 Jul 2003 20:47:53 +1000
Herbert Xu <[email protected]> wrote:
> On Wed, Jul 23, 2003 at 03:35:05AM -0700, David S. Miller wrote:
> > If I know your password is 7 characters I have a smaller
> > space of passwords to search to just brute-force it.
>
> It's much smaller if you didn't know that it was at most 7 characters
> long. However, if you did know the upper bound, or you were just
> brute forcing all passwords starting from 1 character, then the
> difference is relatively minor. This is because
>
> n + n^2 + n^3 + n^4 + n^5 + n^6
>
> is much smaller than n^7 where n is something like 62 for a reasonable
> password.
"7" in my example is an arbitrary number, increase it to any larger
number you like.
On Wed, Jul 23, 2003 at 03:50:22AM -0700, David S. Miller wrote:
>
> > It's much smaller if you didn't know that it was at most 7 characters
> > long. However, if you did know the upper bound, or you were just
> > brute forcing all passwords starting from 1 character, then the
> > difference is relatively minor. This is because
> >
> > n + n^2 + n^3 + n^4 + n^5 + n^6
> >
> > is much smaller than n^7 where n is something like 62 for a reasonable
> > password.
>
> "7" in my example is an arbitrary number, increase it to any larger
> number you like.
Well, as m gets larger, the number
(n + n^2 + ... + n^(m-1)) / n^m
tends to 1 / (n - 1).
In other words, if you can break n^m, then you can probably break
n + n^2 + ... + n^m
Anyway, I'm not that bothered with making /proc/tty/driver root-only,
even if it is only for what seems to me to be dubious reasons.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Wed, Jul 23, 2003 at 03:35:05AM -0700, you [David S. Miller] wrote:
> On Wed, 23 Jul 2003 19:56:47 +1000
> Herbert Xu <[email protected]> wrote:
>
> > Aschwin Marsman <[email protected]> wrote:
> > >
> > >> CAN-2003-0461: /proc/tty/driver/serial reveals the exact character counts
> > >> for serial links. This could be used by a local attacker to infer password
> > >> lengths and inter-keystroke timings during password entry.
> >
> > What's the problem with exposing those counters?
>
> If I know your password is 7 characters I have a smaller
> space of passwords to search to just brute-force it.
Further, if you monitor the /proc/tty/driver/serial character counts with
small enough resolution, I guess you could learn the delays between
individual key presses when the user enters his password. This can be used
to further aid the brute force attack (delays between different key pairs
have different average delays statistically, just as different characters
have different frequencies in a given language. I think there is a paper on
this, and someone suggested an attack like this for snooping ssh
passwords.)
-- v --
[email protected]
> > If I know your password is 7 characters I have a smaller
> > space of passwords to search to just brute-force it.
>
> It's much smaller if you didn't know that it was at most 7 characters
> long. However, if you did know the upper bound, or you were just
> brute forcing all passwords starting from 1 character, then the
> difference is relatively minor. This is because
>
> n + n^2 + n^3 + n^4 + n^5 + n^6
>
> is much smaller than n^7 where n is something like 62 for a reasonable
> password.
>
> So if your password was broken using this method, then it's probably
> too short anyway.
One time passwords are much more secure.
John.
>
> > > If I know your password is 7 characters I have a smaller
> > > space of passwords to search to just brute-force it.
> >
> > It's much smaller if you didn't know that it was at most 7 characters
> > long. However, if you did know the upper bound, or you were just
> > brute forcing all passwords starting from 1 character, then the
> > difference is relatively minor. This is because
<snip>
> One time passwords are much more secure.
Nope.
Changing password to a password of similar complexity every 10 seconds
doesn't make it much less likely to be guessed than a static password.
It may mean you can't guess it again, but you generally don't want
an attacker to even log in once.
One-time passwords, using a key generator may be better for other
reasons for example, more entropy than "31137" or other passwords that
users might pick, or be able to remember.
> > > > If I know your password is 7 characters I have a smaller
> > > > space of passwords to search to just brute-force it.
> > >
> > > It's much smaller if you didn't know that it was at most 7 characters
> > > long. However, if you did know the upper bound, or you were just
> > > brute forcing all passwords starting from 1 character, then the
> > > difference is relatively minor. This is because
> <snip>
> > One time passwords are much more secure.
>
> Nope.
> Changing password to a password of similar complexity every 10 seconds
> doesn't make it much less likely to be guessed than a static password.
For the attack in question, it does, as long as no two consecutive
passwords have the same number of characters.
For example, if the list of OTPs is:
alpha
beta
epsilon
The user logs in using the first password, and somebody logs that it
has five characters. The next valid password, (the only valid one),
has four.
John.
On Wed, 23 Jul 2003, John Bradford wrote:
> > > > > If I know your password is 7 characters I have a smaller
> > > > > space of passwords to search to just brute-force it.
> > > >
> > > > It's much smaller if you didn't know that it was at most 7 characters
> > > > long. However, if you did know the upper bound, or you were just
> > > > brute forcing all passwords starting from 1 character, then the
> > > > difference is relatively minor. This is because
> > <snip>
> > > One time passwords are much more secure.
> >
> > Nope.
> > Changing password to a password of similar complexity every 10 seconds
> > doesn't make it much less likely to be guessed than a static password.
>
> For the attack in question, it does, as long as no two consecutive
> passwords have the same number of characters.
>
> For example, if the list of OTPs is:
>
> alpha
> beta
> epsilon
>
> The user logs in using the first password, and somebody logs that it
> has five characters. The next valid password, (the only valid one),
> has four.
And what if we forget using passwords and use a physical device, a smart
card e.g. like SUN is using to get acces to your desktop all over the
world? Is there support for Linux for an application like that?
> John.
Have fun,
Aschwin Marsman
--
aYniK Software Solutions all You need is Knowledge
P.O. box 134 NL-7600 AC Almelo - the Netherlands
[email protected] http://www.aYniK.com
Herbert Xu wrote:
>On Wed, Jul 23, 2003 at 03:35:05AM -0700, David S. Miller wrote:
>> If I know your password is 7 characters I have a smaller
>> space of passwords to search to just brute-force it.
>
>It's much smaller if you didn't know that it was at most 7 characters
>long.
Yes, if I know I want to attack David Miller's password,
and I'm going to keep trying until I succeed, then knowing
the length of his password doesn't help much. However, if
I'm on a multi-user system and I just want to crack any
password for any one of the users on that system, then
knowing the lengths of passwords does help, because I can
focus my effort on those users with the shortest passwords.
Thus, revealing password lengths might heighten the risk of
password guessing (even if only by a small factor).
Ville Herva wrote:
>Further, if you monitor the /proc/tty/driver/serial character counts with
>small enough resolution, I guess you could learn the delays between
>individual key presses when the user enters his password. This can be used
>to further aid the brute force attack (delays between different key pairs
>have different average delays statistically, just as different characters
>have different frequencies in a given language. I think there is a paper on
>this, and someone suggested an attack like this for snooping ssh
>passwords.)
Yes. The paper describing the attack on SSH is here:
http://www.cs.berkeley.edu/~daw/papers/ssh-use01.ps
http://www.cs.berkeley.edu/~daw/papers/ssh-use01.pdf
Dawn Xiaodong Song, David Wagner, and Xuqing Tian,
"Timing Analysis of Keystrokes and Timing Attacks on SSH",
10th USENIX Security Symposium, 2001.
A nice summary can be found here:
http://linux.oreillynet.com/lpt/a/linux/2001/11/08/ssh_keystroke.html
On Wed, Jul 23, 2003 at 08:59:03PM +1000, Herbert Xu wrote:
> Anyway, I'm not that bothered with making /proc/tty/driver root-only,
> even if it is only for what seems to me to be dubious reasons.
Or maybe it is possible to update this information with a longer period.
Let's say for example 5 seconds. So it is almost impossible to determine
the length of a password.
It is a little more complicated, but it has the advantage that the
statistics about the serial ports are still available for normal users.
Aurelien
On Mer, 2003-07-23 at 21:16, Aurelien Jarno wrote:
> Or maybe it is possible to update this information with a longer period.
> Let's say for example 5 seconds. So it is almost impossible to determine
> the length of a password.
In some cases that is still useful information. People brought up the
IRQ data and to be honest that also is something I'd prefer wasn't non
root viewable.
"David S. Miller" <[email protected]> writes:
> If I know your password is 7 characters I have a smaller
> space of passwords to search to just brute-force it.
This is not the real problem, IMHO.
If the counter is public, you can read it repeatedly to measure the
intervals between keypresses. If you take pair-wise timing into
account, you can narrow the search space considerably.
There's a detailed paper about the issue:
<http://www.ece.cmu.edu/~dawnsong/papers/ssh-timing.pdf>
(Even if the title says SSH, it applies to the public counter scenario
as well.)