Upcoming OpenSSH vulnerability
| From: | Theo de Raadt <deraadt@cvs.openbsd.org> | |
| To: | ||
| Subject: | Upcoming OpenSSH vulnerability | |
| Date: | Mon, 24 Jun 2002 15:00:10 -0600 | 
------- Blind-Carbon-Copy To: bugtraq@securityfocus.com cc: dsi@iss.net cc: announce@openbsd.org cc: misc@openbsd.org Subject: Upcoming OpenSSH vulnerability Date: Mon, 24 Jun 2002 15:00:10 -0600 From: Theo de Raadt <deraadt@cvs.openbsd.org> There is an upcoming OpenSSH vulnerability that we're working on with ISS. Details will be published early next week. However, I can say that when OpenSSH's sshd(8) is running with priv seperation, the bug cannot be exploited. OpenSSH 3.3p was released a few days ago, with various improvements but in particular, it significantly improves the Linux and Solaris support for priv sep. However, it is not yet perfect. Compression is disabled on some systems, and the many varieties of PAM are causing major headaches. However, everyone should update to OpenSSH 3.3 immediately, and enable priv seperation in their ssh daemons, by setting this in your /etc/ssh/sshd_config file: UsePrivilegeSeparation yes Depending on what your system is, privsep may break some ssh functionality. However, with privsep turned on, you are immune from at least one remote hole. Understand? 3.3 does not contain a fix for this upcoming bug. If priv seperation does not work on your operating system, you need to work with your vendor so that we get patches to make it work on your system. Our developers are swamped enough without trying to support the myriad of PAM and other issues which exist in various systems. You must call on your vendors to help us. Basically, OpenSSH sshd(8) is something like 27000 lines of code. A lot of that runs as root. But when UsePrivilegeSeparation is enabled, the daemon splits into two parts. A part containing about 2500 lines of code remains as root, and the rest of the code is shoved into a chroot-jail without any privs. This makes the daemon less vulnerable to attack. We've been trying to warn vendors about 3.3 and the need for privsep, but they really have not heeded our call for assistance. They have basically ignored us. Some, like Alan Cox, even went further stating that privsep was not being worked on because "Nobody provided any info which proves the problem, and many people dont trust you theo" and suggested I "might be feeding everyone a trojan" (I think I'll publish that letter -- it is just so funny). HP's representative was downright rude, but that is OK because Compaq is retiring him. Except for Solar Designer, I think none of them has helped the OpenSSH portable developers make privsep work better on their systems. Apparently Solar Designer is the only person who understands the need for this stuff. So, if vendors would JUMP and get it working better, and send us patches IMMEDIATELY, we can perhaps make a 3.3.1p release on Friday which supports these systems better. So send patches by Thursday night please. Then on Tuesday or Wednesday the complete bug report with patches (and exploits soon after I am sure) will hit BUGTRAQ. Let me repeat: even if the bug exists in a privsep'd sshd, it is not exploitable. Clearly we cannot yet publish what the bug is, or provide anyone with the real patch, but we can try to get maximum deployement of privsep, and therefore make it hurt less when the problem is published. So please push your vendor to get us maximally working privsep patches as soon as possible! We've given most vendors since Friday last week until Thursday to get privsep working well for you so that when the announcement comes out next week their customers are immunized. That is nearly a full week (but they have already wasted a weekend and a Monday). Really I think this is the best we can hope to do (this thing will eventually leak, at which point the details will be published). Customers can judge their vendors by how they respond to this issue. OpenBSD and NetBSD users should also update to OpenSSH 3.3 right away. On OpenBSD privsep works flawlessly, and I have reports that is also true on NetBSD. All other systems appear to have minor or major weaknesses when this code is running. (securityfocus postmaster; please post this through immediately, since i have bcc'd over 30 other places..) ------- End of Blind-Carbon-Copy
      Posted Jun 25, 2002 8:33 UTC (Tue)
                               by garloff (subscriber, #319)
                              [Link] (5 responses)
       
     
    
      Posted Jun 25, 2002 10:00 UTC (Tue)
                               by DeletedUser2238 ((unknown), #2238)
                              [Link] (4 responses)
       So they first work around the bug, without actually fixing the bug and telling what is it and where it is, so crackers can't make an exploit before people are immune (and I repeat, a direct fix would exactly tell the cracker what the bug is.) A bug like this is what every cracker is dreaming of, a way into just about every unix machine on the planet!
      
           
     
    
      Posted Jun 25, 2002 10:38 UTC (Tue)
                               by DeletedUser2239 ((unknown), #2239)
                              [Link] (3 responses)
       I don't know with what agenda the advisory was released, I can't refute the statement that a workaround which defuses the Furthermore I find the statements made by theo in his release very "Customers can judge their vendors by how they respond to this issue." Is one of them. And again there seems to me to be too much old grief and sorrow in Sure people can differ in opinion, but when it comes to these kinds 
      
           
     
    
      Posted Jun 25, 2002 12:37 UTC (Tue)
                               by DeletedUser2242 ((unknown), #2242)
                              [Link] (1 responses)
       "the world of free source" thrives on opinionated stupidity. Nobody Add to that - when you look at their (usually comment-free) code, it's 
      
           
     
    
      Posted Jun 27, 2002 10:58 UTC (Thu)
                               by DeletedUser2239 ((unknown), #2239)
                              [Link] 
       Ok can't refute your statement. But it seems my motives are too naive for a burdend free source And indeed opinionated stupidity is the basis on which theo released 
     
      Posted Jun 25, 2002 12:44 UTC (Tue)
                               by DeletedUser2242 ((unknown), #2242)
                              [Link] 
       "Customers can judge their vendors by how they respond to this issue." This is *absolutely* 100% spot-on.  Suggesting otherwise has the Grow up kiddies. Shut up and fix it instead of wasting everyones time 
     
    
      This statement from Theo really makes one wonder what's going on.Upcoming OpenSSH vulnerability
      
If a vulnerability is found in a software package, what the one who
discovers should do is to contact the authors of the software.
This apparently happened in this case. The next step for the authors
is to fix the problem and contact distributors. There are mailing
lists to coordinate these efforts. A few days later, most distributors
should have fixes ready and the disclosure of the vulnerability can
happen and all distros can send their sec announcements within a short
amount of time.
For some reason Theo seems to imply he does not want to follow this
procedure. Instead he wants that the distributors implement a workaround
beforehand. Strange way of dealing!
After reading about the Privilege Separation stuff it sounds like a very
good idea to me. After reading Theo's "I want to force it down your
throats" I'm not so sure any more ...
      
          
      If the details to this vulnerability would have been released (even with patches)  just about every Linux box on the planet would have been cracked before the owners would've had time to install the patch. Publishing a fix to this problem will only tell the cracker exactly where the problem is.Upcoming OpenSSH vulnerability
      
      http://docs.freebsd.org/cgi/getmsg.cgi?fetch=255989+0+current/freebsd-securityUpcoming OpenSSH vulnerability
      
but one can't call it an innocent one.
so called hole into nothing more then an unprivilidge accoutn getting
compromised. Is a good in between step.
 
But a real fix ready monday next week ? that's not an option. today
or tomorrow is.
dubious.
the initial announcements and all reactions. 
of threats we "the world of free source",both users and developers, need 
to stick together.
And "the world of free source" has thrived by sharing ideas and problems.
      That's the biggest crock I've ever heard.Upcoming OpenSSH vulnerability
      
ever really fixes anything well, because the opinionated dickhead who
ends up dong the fix always decides it's "somebody elses problem", and
wastes shitloads more time arguing about why they should not have to
be the person to solve something or other than it would have taken to
just do as they're asked in the first place.
always amazing that any fix works at all.
      Heh,Upcoming OpenSSH vulnerability
      
I think I should have made my point by stating that
the motive I describe is one to go by.
Or I could throw in responsibility...
user/developer.
the "preliminary" advisory and the following I might add.
      
          
      As for the statement:-Upcoming OpenSSH vulnerability
      
identical effect as tattooing "I am the lazy and opinionated stupid
idiot who prefers to argue why it's not my job to fix a problem rather
than just fix a problem" on your forehead.
and proving you care more for the survival of your own (dumb) opinions
than for the safety of everyone else.
      
          
 
           