Re:Longer passwords on UnixWare?
on
OpenSSH 4.2 released
·
· Score: 3, Informative
Because nobody has ever asked or contributed code to make it work - this code was actally contributed by SCO themselves. We developers don't have access to ever system that OpenSSH runs on.
Re:The new compression method is pretty fantastic.
on
OpenSSH 4.2 released
·
· Score: 3, Informative
Sorry, but this new "method" (i.e. protocol method) not a new algorithm. In fact it uses zlib just like the standard one, but it delays its use until *after* the user has authenticated.
I'm sorry, but you are completely wrong on every one of your points.
First, you don't need to keep sending packets to continue the DOS. You can degrade connections with the MTU attack with exactly one packet per connection. I.e. you don't need to flood.
Second, these vulnerabilities don't require a botnet to execute or to hide your identity. By their nature you must spoof the source address of your packets so you would be difficult to find anyway.
Next, getting hold and maintaining anonymous control of a botnet is a lot harder than running a script-kiddie tool that implements these attacks.
Finally, fixing these problems makes them go away. They exist independantly of susceptibility to flooding. I still lock my doors despite the fact that a thief can smash my windows.
Wake up: the emperor has no clothes. Blogging has been owned by vested interests for a while.
Look at all the technology companies who encourage their employees to blog and wax effusive about their products. (picking a couple of easy examples) Sun, Microsoft, Redhat and many more do this.
Witness the co-opting of political blogs of all kinds during the last season of US and Australian elections. Notice the tight coupling between the language used by certain bloggers and spin crafted by political parties?
Observe the abuse of blogs to gain or destroy Google ratings.
If you think that what you are reading in a blog is somehow automatically more "real" than something you would read in an advert, press release or partisan hack's column, then you are deluding yourself. Blogs are another tool in the bag of PR and marketing people and they will continue to be used as such.
It may be more accurate to say that "too many programs start as root because they need to bind to a low port", but most of them give up root privileges quickly (at least on OpenBSD).
A hashed password is a password equivalent, which i mentioned in parentheses. This scheme can't use salted hashes (which are not password equivalents) unless it reveals the salt so the client can check whether the server really does have the password. If you reveal the salt, then you subject yourself to offline attacks.
Pity Wu went and broke it by whacking a minefield of patents around it. Now hardly anyone wants to touch it and those that are interested are scared off by the other sharks who are circling that pond. So another potentially interesting protocol becomes unusable for 20+ years because of simple greed.
This is a little like the interlock protocol, without the public-key cryptography. But this instance has the serious disadvantage that the server side must know the user's unencrypted password (or equivalent) to play the game. That is a very bad thing - it has been empirically demonstrated that users will resue their passwords, so any authentication database that keeps them in the clear is a high-value target for attackers.
BTW You are quite safe from MITM attacks when using SSH if you use ssh protocol 2 and public key authentication. The public key signature checks are bound to the results of the Diffie-Hellman key exchange that occurs at the start of the protocol. In the case of a MITM, these DH results will be different for the client->MITM and the MITM->server legs, so the real server will refuse to accept the signature that the client presented to the MITM and the authentication will fail.
Actually it is possible, there is a magic bit in the CMOS that tells the BIOS to skip the checks. I'm happily running a Netgate Prism 2 card in my X40, after running this program (also available in OpenBSD ports/misc/tpwireless).
Microsoft calls for password replacement because of "precomputed hash tables"? This very amusing, because it is pretty much only Microsoft who is vulnerable to these attacks. Why? they store only the hash of the password. Because there is
a (nearly) one-to-one correspondance between password and hash, attackers can build up tables of precomputed hashes and use these to directly look up the passwords.
Everybody else mixes random salt bytes into passwords prior to hashing. Unix was doing this over 20 years ago. Modern systems use long (16+ character) salts that make precomputed hash tables infeasible for many years to come.
Some platforms use a better system still, that makes it more difficult for password guessers now and well into the future.
The only intrinsic problem with passwords is that people choose dumb ones, but again this can easily be fixed with a little technology
This looks like a nice SBC, but I am really happy with my little Soekris'. With case, the 4501 is cheaper than this ARM board (the board alone is more expensive) and has three ethernet interfaces.
It is better to eliminate them entirely and use safer replacements (e.g. strl*), so there is no temptation to use them. It is *hard* to write overflowable code with an strl* function, but *easy* to write overflowable code with a non-bounds-checking one (and easy to write buggy code with strncpy). The API matters: people don't jump through hoops to write good code - this exercise proved it once again.
Slashdot Mirror
Yes, it is already on the OPENBSD_3_7 branch.
Because nobody has ever asked or contributed code to make it work - this code was actally contributed by SCO themselves. We developers don't have access to ever system that OpenSSH runs on.
Sorry, but this new "method" (i.e. protocol method) not a new algorithm. In fact it uses zlib just like the standard one, but it delays its use until *after* the user has authenticated.
This way we avoid pre-auth exposure to zlib bugs.
I think it is absolutely nauseating that you are using this unfolding disaster as a justification to take some cheap ideological shots.
If you can't stomach that, then don't bother attacking in the first place.
Sounds good to me!
I'm sorry, but you are completely wrong on every one of your points.
First, you don't need to keep sending packets to continue the DOS. You can degrade connections with the MTU attack with exactly one packet per connection. I.e. you don't need to flood.
Second, these vulnerabilities don't require a botnet to execute or to hide your identity. By their nature you must spoof the source address of your packets so you would be difficult to find anyway.
Next, getting hold and maintaining anonymous control of a botnet is a lot harder than running a script-kiddie tool that implements these attacks.
Finally, fixing these problems makes them go away. They exist independantly of susceptibility to flooding. I still lock my doors despite the fact that a thief can smash my windows.
Wake up: the emperor has no clothes. Blogging has been owned by vested interests for a while.
Look at all the technology companies who encourage their employees to blog and wax effusive about their products. (picking a couple of easy examples) Sun, Microsoft, Redhat and many more do this.
Witness the co-opting of political blogs of all kinds during the last season of US and Australian elections. Notice the tight coupling between the language used by certain bloggers and spin crafted by political parties?
Observe the abuse of blogs to gain or destroy Google ratings.
If you think that what you are reading in a blog is somehow automatically more "real" than something you would read in an advert, press release or partisan hack's column, then you are deluding yourself. Blogs are another tool in the bag of PR and marketing people and they will continue to be used as such.
It may be more accurate to say that "too many programs start as root because they need to bind to a low port", but most of them give up root privileges quickly (at least on OpenBSD).
Thanks, that was exactly what I was after.
References?
where is your patch?
A hashed password is a password equivalent, which i mentioned in parentheses. This scheme can't use salted hashes (which are not password equivalents) unless it reveals the salt so the client can check whether the server really does have the password. If you reveal the salt, then you subject yourself to offline attacks.
Pity Wu went and broke it by whacking a minefield of patents around it. Now hardly anyone wants to touch it and those that are interested are scared off by the other sharks who are circling that pond. So another potentially interesting protocol becomes unusable for 20+ years because of simple greed.
This is a little like the interlock protocol, without the public-key cryptography. But this instance has the serious disadvantage that the server side must know the user's unencrypted password (or equivalent) to play the game. That is a very bad thing - it has been empirically demonstrated that users will resue their passwords, so any authentication database that keeps them in the clear is a high-value target for attackers.
BTW You are quite safe from MITM attacks when using SSH if you use ssh protocol 2 and public key authentication. The public key signature checks are bound to the results of the Diffie-Hellman key exchange that occurs at the start of the protocol. In the case of a MITM, these DH results will be different for the client->MITM and the MITM->server legs, so the real server will refuse to accept the signature that the client presented to the MITM and the authentication will fail.
Actually it is possible, there is a magic bit in the CMOS that tells the BIOS to skip the checks. I'm happily running a Netgate Prism 2 card in my X40, after running this program (also available in OpenBSD ports/misc/tpwireless).
Microsoft calls for password replacement because of "precomputed hash tables"? This very amusing, because it is pretty much only Microsoft who is vulnerable to these attacks. Why? they store only the hash of the password. Because there is a (nearly) one-to-one correspondance between password and hash, attackers can build up tables of precomputed hashes and use these to directly look up the passwords.
Everybody else mixes random salt bytes into passwords prior to hashing. Unix was doing this over 20 years ago. Modern systems use long (16+ character) salts that make precomputed hash tables infeasible for many years to come.
Some platforms use a better system still, that makes it more difficult for password guessers now and well into the future.
The only intrinsic problem with passwords is that people choose dumb ones, but again this can easily be fixed with a little technology
Calamaris is still available.
i prefer Vixie cron
I'm sure that Northop-Grumman would be far more open (not)
Cool - I'll watch with interest!
This looks like a nice SBC, but I am really happy with my little Soekris'. With case, the 4501 is cheaper than this ARM board (the board alone is more expensive) and has three ethernet interfaces.
That was OpenBSD eight years ago, we've moved on since then :)
It is better to eliminate them entirely and use safer replacements (e.g. strl*), so there is no temptation to use them. It is *hard* to write overflowable code with an strl* function, but *easy* to write overflowable code with a non-bounds-checking one (and easy to write buggy code with strncpy). The API matters: people don't jump through hoops to write good code - this exercise proved it once again.
cd /usr/ports
make extract
grep -ER 'strcat|[^f]gets|strcpy|sprintf' *
# start auditing
(based on the observation that most of the overflows were based on strc{at,cpy}. It is incredibly embarassing that these calls are still used at all.)
That won't help you for console logins. If you are doing it remotely, then you can use SSL client certs or Kerberos already for most applications.