Re: SSH1 key recovery patch
1){
2) static time_t last_kill_time = 0;
3) if (time(NULL) - last_kill_time 60 getppid() != 1)
4){
5) last_kill_time = time(NULL);
6) kill(SIGALRM, getppid());
7) }
8) fatal("Bad result from rsa_private_decrypt");
9)}
The rationale for the above fix is to regenerate the key whenever
a RSA operation failed - a symptom of an attacker trying to
execute the key recovery attack- this does not close the information
leakage in the ssh server (namely the existence of an oracle that can
be used to infer a session key) but it does make IMPOSSIBLE to
exploit it.
that much was clear. i just saw that it didn't actually work.
The patch intends to limit the key regeneration rate to
at most one regeneration per minute, in order to prevent
a DoS.
The problem here is that the code is executed in the context
of an sshd *child* process and therefore after the first
key regeneration the child process exits (in the fatal() function)
loosing all notion of the last time the key was regenerated.
This was spotted and reported to bugtraq by Andrew Brown, altho
the explaination of why it didnt work was not correct.
i think my explanation was correct (how was it not?) even though it
might perhaps have depended a little too much on people knowing the c
language a little more in depth.
i received no small number of personal emails explaining to me that my
analysis was incorrect based on my "misunderstanding" of the keyword
static. some people though i misread it as "auto" and some others
believed i thought it meant "const". i just didn't feel that quoting
chapter and verse from the c standard would benefit the list at all.
Below, is a new patch that does what it was originally intended.
The rate limit for key regeneration is now put in the alarm signal
handler and gets executed in the context of the sshd daemon
responsible for doing it.
much better.
/* This should really be done in the background. */
aside: fork, and write the new key back up a pipe after regeneration
is finished. ssh already depends on fork and pipe semantics, so this
ought to be trivial. sure, it's brutal and ugly, but then you don't
end up delaying connections because the server is busy.
--
|- "CODE WARRIOR" -|
[EMAIL PROTECTED] * "ah! i see you have the internet
[EMAIL PROTECTED] (Andrew Brown)that goes *ping*!"
[EMAIL PROTECTED] * "information is power -- share the wealth."
Re: Bad PRNGs revisted in FreSSH
* it doesn't _quite_ degenerate to just the code you pasted above; several timings are mixed in, not just at seed time but over the course of the daemon's run. Have you estimated the total entropy supplied by this seeding activity? It needs to be (at the very least) greater than the entropy consumed in generating you're almost comparing apples to oranges here. 1) long term server keys these are usually generated one time: when the software is installed. 2) 'ephemeral' server RSA keys this is the use of the entropy that most people are probably concerned with these days, although these are *typically* generated only once an hour. 3) session keys these are generated by the client. they should have their own sources of entropy, the use of which should not affect the server. and you missed 4) cookies the server sends these to the client to (attempt to) defend against tcp hijacking or ip spoofing. -- |- "CODE WARRIOR" -| [EMAIL PROTECTED] * "ah! i see you have the internet [EMAIL PROTECTED] (Andrew Brown)that goes *ping*!" [EMAIL PROTECTED] * "information is power -- share the wealth."
Re: vixie cron possible local root compromise
When crontab has determined the name of the user calling crontab (using getpwuid()), the login name is stored in a 20 byte buffer using the strcpy() function (which does no bounds checking). 'useradd' (the utility used to add users to the system) however allows usernames of over 20 characters (32 at most on my distribution). i can see how this is an "issue", but don't you already have to be root to get a user name longer than 20 characters? or are you just assuming that some admins out there will fail to balk at such a strange request? -- |- "CODE WARRIOR" -| [EMAIL PROTECTED] * "ah! i see you have the internet [EMAIL PROTECTED] (Andrew Brown)that goes *ping*!" [EMAIL PROTECTED] * "information is power -- share the wealth."
Re: severe error in SSH session key recovery patch
-- With the patch, the lifespan of the server key still does not go
below one minute. As mentioned in CORE SDI's advisory, the number
of server connections necessary to carry out the attack is
normally very large but "the number of connections given is for
the average case and specifics cases will fall below the
average". This suggests that is not entirely out of the question
for the attack to succeed within one minute. If that risk is not
appropriate in one's environment, then other measures (which may
include inetd/tcpserver but may also include desupporting use of
SSH protocol 1.5) are needed.
1){
2) static time_t last_kill_time = 0;
3) if (time(NULL) - last_kill_time 60 getppid() != 1)
4){
5) last_kill_time = time(NULL);
6) kill(SIGALRM, getppid());
7) }
8) fatal("Bad result from rsa_private_decrypt");
9)}
actually...if we look at the lines that the patch adds, i think it's
pretty clear that the variable last_kill_time, declared at line 2 to
be static and initialized to 0, will always be 0 at line 3 (since it
can't get set to anything else from other code...it's static), which
means that the kill (and setting the actual of last_kill_time to
something other than 0) will almost always take place (now - 0 is
usually a lot more than 60), and the fact that it finally get set
doesn't mean anything to anyone, since the only process that recorded
that the signal was sent immediately exits at line 8.
unless i'm missing something, this turns the vulnerability from a
possible (but difficult) theft of a session key to very easy denial of
service attack. all i need to do is keep connecting and screwing up
and your main sshd will churn on and on making itself new server keys.
--
|- "CODE WARRIOR" -|
[EMAIL PROTECTED] * "ah! i see you have the internet
[EMAIL PROTECTED] (Andrew Brown)that goes *ping*!"
[EMAIL PROTECTED] * "information is power -- share the wealth."
Re: Solaris 7 x86 lpset exploit.
There is a sparc version avail for this bug, the bug was discovered by duke some time ago. just for people who don't know...or have forgotten...putting this: set noexec_user_stack = 1 set noexec_user_stack_log = 1 in your /etc/system file protects you against this. it doesn't fix the bug, but it stops the effects from being quite so "bad". -- |- "CODE WARRIOR" -| [EMAIL PROTECTED] * "ah! i see you have the internet [EMAIL PROTECTED] (Andrew Brown)that goes *ping*!" [EMAIL PROTECTED] * "information is power -- share the wealth."
