OpenSSH version bump to 3.4

Contributed by jose on 2002-06-26 from the fixing-the-ints dept.

floh writes :

"Markus Friedl just bumped the OpenSSH version to 3.4, and commited a fix for the "int overflow; from ISS", the commit message should be here "

The commit message from Markus is


From: Markus Friedl

Date: Wed, 26 Jun 2002 07:55:38 -0600 (MDT)
Subject: CVS: cvs.openbsd.org: src

CVSROOT:        /cvs
Module name:    src
Changes by:     markus@cvs.openbsd.org  2002/06/26 07:55:37

Modified files:
        usr.bin/ssh    : auth2-chall.c

Log message:
make sure # of response matches # of queries, fixes int overflow; from ISS

The ISS advisory contains additional information on the vulnerability.

As the commit message said , nearly six years ... not bad. Update The OpenSSH advisory is now also available.

(Comments are closed)

Comments

By Anonymous Coward () on 2002-06-26 16:14

One remote hole in the default install, in nearly 6 years!
Comments
1. By Anonymous Coward () on 2002-06-26 16:21
  
  That's pretty sad considering that next to nothing is enabled in the default install, making it pretty useless to begin with. You'd think people would at least get it right with so little to worry about. Oh wait, when things go wrong "I get what I pay for."
  Comments
  1. By Anonymous Coward () on 2002-06-26 16:28
    
    bullshit. a bunch of stuff is enabled by default, including portmap. whens the last time you saw a portmap exploit in openbsd? and one in linux/solaris/irix? ident? comsat? rstatd and ruserd?
    
    its not useless, its svelte. plus when you turn on named you're not going to bite your nails, they're audited it (granted its missing some bind 8 and 9 features, but ...).
    
    as for getting it right, if you dont like it, dont use it or start helping.
  2. By DieNadel () on 2002-06-26 17:02
    
    I guess you could say that you get a lot more than what you pay for. You've got a reliable, stable and, yes, secure OS for close to nothing. Anyone that has half a brain knows that bugs are likely to show up sooner or later, and we can be proud that it was later.
    Now stop bugging and try to find some more bugs! :-)
  3. By Anonymous Coward () on 2002-06-26 21:04
    
    Well, go pay for Windows 2K or Windows XP. You get a lot more vulnerabilities per dollar... Or maybe you want to pay for Solaris, HP/UX, Dynix or AIX. Still more vulnerabilities. Maybe you should just unplug your computer from any networks, remove the modem and spare all of us your infantile intellect.
  4. By pravus () on 2002-06-27 04:12
    
    You'd think people would at least get it right with so little to worry about.
    
    yeah, you are right. 70MB of kernel source is trivial to maintain.
    
    please... for the sake of humanity, put the crack pipe down.
2. By Anonymous Coward () on 2002-06-26 20:20
  
  A fact and a good prestation if you'd ask me.
3. By lx () asdf on 2002-06-26 22:17 mailto:asdf
  
  Definitely an improvement, I'm glad they've changed it. Eventually I'd like to see them abandon the statement completely or change it to something more accurate like "One remote root hole in the default install, at least in the most current available version of the operating system available at the time, in nearly 6 years."
  Comments
  1. By pravus () on 2002-06-27 04:21
    
    density suits you.
    
    check your history. the statement is true. take a release from 5 years ago... use the default installation... how many remote exploits do you have? at most, 1: this new OpenSSH exploit.
    
    what is so hard to understand about this? i just don't get it. maybe the people that complain so much about this statement don't speak english very well?
4. By Ken Wronkiewicz () on 2002-06-27 00:56 http://www.wirewd.com/wh/
  
  It needs a smiley.
5. By Anonymous Coward () on 2002-06-27 02:12
  
  Patch # 8 is out.
  Check the errata for 3.1
  holy crap.
  Comments
  1. By Anonymous Coward () on 2002-06-27 02:42
    
    This is going to keep happening until the OpenBSD shifts to security-by-design. Right now, OpenBSD's focus is security by software quality. That's great but unfortunately there is no way to write a large amount of code in C and not have the occasional overflow or other security compromising bug.
    There are a few ways to achieve security by design. Fine-grained capabilities is an excellent approach. Privsep in the new OpenSSH takes this idea. We need to use this kind of thing all over the place. The other approach is to stop using languages like C for network services. It just isn't humanly possible to write a large body of C code without the occasional overflow. The OpenBSD team is the best in the world, and yet bugs still get through, as we have seen recently.
    
    Comments
    
    By Anonymous Coward () on 2002-06-27 03:22
    
    All right then. Thanks for volunteering your time.
    How soon can you have a spec written up?
    
    By couderc () on 2002-06-28 01:54
    
    How many times should we say NO JAVA ? :)
By M Shannon () on 2002-06-26 16:17

Well I can't say I didn't want it to last forever. But I guess if it had to go, we should let it go with dignity.

Way to go guys, you've done great work release after release. I expect to see a new streak start again.

It was a hard week for OpenBSD, Apache exploit toolkits, Openssh vulnerabilites, bad press everywhere you turn.

Well, just so there's no mis-understanding, put me down for a 3.2 CD!

-M
Comments
1. By Anonymous Coward () on 2002-06-26 16:59
  
  I just downloaded ALL the patches for 2.9 3.0 and 3.1
  2.9.tar.gz---314934
  3.0.tar.gz --249440
  3.1.tar.gz - 7267
  -This is a walk in the park compared to my other
  -platforms. They fit on one floppy!!!
  Do you have any idea how long it would take for
  the updates for the last 3 releases of SuSE? or redhat?
  HOURS. Really. hours. They fill up a whole CD.
  OpenBSD kicks butt.
  Comments
  1. By Anonymous Coward () on 2002-06-26 17:02
    
    Hard to tell from the last post but I agree with you.
    It seems like somebody is gunning for theo.
    Well as they will find out, We are very loyal.
    
    Comments
    
    By Jeff Flowers () jeffrey@jeffreyf.net on 2002-06-26 17:16 mailto:jeffrey@jeffreyf.net
    
    "It seems like somebody is gunning for theo"
    
    I think some of that has to do with Theo himself. I have no problem with Theo as I appreciate his bluntness but I can see how some would. I suspect that makes him, and OpenBSD, a target for some.
    
    Regardless, Theo and his fellows have shown what can be accomplished if one is willing to work.
By Anonymous Coward () on 2002-06-26 17:24

Apparently it's worked fine for the past two releases, but not for 3.4. I'd be okay with that, except the client has been changed to not complete a connection if compression fails, versus falling back to no compression. This is a real pain, as I like to alias ssh -C on all my machines regardless of whether or not I'm connecting to a server that I run. Please give me back my compression.
By pravus () on 2002-06-26 17:25

... at least for the people that do nothing but gripe about the "no remote hole" statement. now what will they gripe about? i'm sure they will find something...
Comments
1. By john doe () on 2002-06-26 18:45 http://www.theregister.co.uk/content/4/25891.html
  
  is all this really such an issue? I disable anything I don't need in sshd_config on first use and run it on weird ports on internal interfaces. If people want TOTAL security without thinking, I suggest they let bill do it for them (see link)
By Ben Johnson () ben@remove.johnsonworld.this.com on 2002-06-26 17:30 www.johnsonworld.com

Am I reading the advisory correctly: Affected Versions: OpenBSD 3.0 OpenBSD 3.1 FreeBSD-Current OpenSSH 3.0-3.2.3 Is OpenBSD 2.9 and lower not affected? I'd like to know - as I'm quite lazy.
Comments
1. By Re:<3.0 Not Affected? by<font c () on 2002-06-26 17:35
 
 i would think that the question you need to ask yourself is what version of OpenSSH you are running, regardless of the OS version you have. the bug is in OpenSSH, not OpenBSD.
2. By <3.0 Not Supported by<font colo () on 2002-06-26 19:06
 
 I believe the reason why those versions weren't listed is because they are considered unsupported.
3. By Matt Liggett () mml@pobox.com on 2002-06-26 19:37 http://pobox.com/~mml
 
 According to openssh.org:
 
 At least one major security vulnerability exists in many deployed OpenSSH versions (2.9.9 to 3.3) . . .
 
 I'm running 2.8, and ssh -V reports that I'm using OpenSSH 2.3.0, so I appear to be safe. ssh -V might provide useful for you, too.
 Comments
 1. By francisco () on 2002-06-26 20:03 http://www.blackant.net/
 
 I'm running 2.8, and ssh -V reports that I'm using OpenSSH 2.3.0, so I appear to be safe.
 as long as you trust your local users, and there is nothing else exploitable on that box (like unpatched apache c.f. http://www.openbsd.org/advisories/ssh_channelalloc.txt
 
 Comments
 
 By Ben Johnson () ben-openbsd@remove.johnsonworld.this.com on 2002-06-27 05:17 mailto:ben-openbsd@remove.johnsonworld.this.com
 
 Thanks for the constructive replies.
 
 I put on my paranoid-tin-foil-hat and took the precaution of considering OpenSSH possibly vunerable - even after the curent patches and have set all my firewalls to block any port 22 trafic with an eception of allowing my static home IP addess in.
 
 Thanks to OpenBSD and OpenSSH for the 5 years of worry free computing. This incident only reminds my of why I moved over to OpenBSD in the first place, and you have my confidence. Heres to the next 5 years.
 
 Cheers.
By RC () on 2002-06-26 22:16

OpenBSD's policy of disabling everything by default is a GREAT policy, IF they do it.

If S/Key and/or BSD_Auth were disabled, this wouldn't have been the end of OpenBSD's reign without a remote Root hole. Most users wouldn't have been affected by disabling S/Key by default, and those few who use it could have re-enabled it.

Anyone care to say why S/Key was enabled? Or better yet, why it was enabled on OpenBSD, but other distros were smart enough to disable it by default.

Additionally, why didn't Theo just let the world know that disabling S/Key would have neutralized the exploit? That's even better than priv seperation, as it would prevent them ANY access!
Comments
1. By Anonymous Coward () on 2002-06-28 04:23
  
  It's not too hard to grep the source for S/Key stuff, and it's not too hard to find a bug when you know where it is. If Theo had said that disabling S/Key fixed the exploit, there would have been a 1337 0-day exploit circulating within fifteen minutes.
2. By Anonymous Coward () on 2002-06-28 04:23
  
  It's not too hard to grep the source for S/Key stuff, and it's not too hard to find a bug when you know where it is. If Theo had said that disabling S/Key fixed the exploit, there would have been a 1337 0-day exploit circulating within fifteen minutes.
By Aasmund () on 2002-06-27 05:58

I finally caved in and upgraded my 2.9 box. However i had several problems:

1. The good-old XML::Parser problem, fixed with --disable-rule=EXPAT (I thought it was officially fixed)
2. $r->print requires full scalar not ref anymore. (for mod_perl)
3. cvs'upping to stable is fine, however, making obj/build fails on "/bin/sh: cd: /usr/src/usr.bin/ssh/ssh-keysign - No such file or directory" any ideas?
4. How easy the upgrade system is, I love it!
5. My system hangs 50% of the time on SCSI detection, I don't have any SCSI units. So I guess I will have to alter GENERIC and recompile.

Thank You,

Aasmund.
Comments
1. By Sam () on 2002-06-27 14:57
  
  >making obj/build fails on "/bin/sh: cd: /usr/src/usr.bin/ssh/ssh-keysign - No such file or directory" any ideas?
  
  Read and follow the upgrading instructions?
  Comments
  1. By Aasmund () on 2002-06-28 02:43
    
    Hmm, I did do my best to follow instructions. Maybe I did something stupid. however the error doesn't look like a config problem more a missing file. That indicates to me a cvs problem. Don't know why it arose. Hope it will be gone now.
    
    Also my system has started to behave erratically. Suddenly it can't find libraries and loses all it's 512 memory. 2 mins later it's ok.
    
    Strange.
2. By Anonymous Coward () on 2002-06-27 16:38
  
  You don't need to recompile the kernel.
  Use config instead and disable unwanted devs.
3. By francisco () on 2002-06-27 16:52 http://www.blackant.net/
  
  5. My system hangs 50% of the time on SCSI detection, I don't have any SCSI units. So I guess I will have to alter GENERIC and recompile.
  i bet it's looking for cd drives. are you seeing something like:
  atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: SCSI0 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
  yours will vary slightly, of course. if this is similar to the problem you are referring to, then you will want to see atapiscsi(4), scsibus(4), and cd(4), which will explain to you what all those drivers are. If you have a Sony cd drive and are running 3.1-release, then you may notice some problems during detection. refer to the mailing lists for more information, and upgrade to the recent stable kernel.
  my machine didnt recognize the cd drive with 3.1-release, though the same drive worked fine with 2.9. it started working in -current a few weeks ago. thank you developers!
By Anonymous Coward () on 2002-06-27 16:01

I've been looking at the code under auth2-chall.c and how it was fixed and I don't see how this was an exploit.

The CVS log mentions an int overflow.

Referring to this snippet of code
=====
nresp = packet_get_int();
if (nresp != kbdintctxt->nreq)
fatal("input_userauth_info_response: wrong number of replies");
if (nresp > 100)
fatal("input_userauth_info_response: too many replies");
if (nresp > 0) {
response = xmalloc(nresp * sizeof(char*));
for (i = 0; i 100) check was the patch.

But if nresp was very large where does the overflow occur? I could see the kernel thrashing for a while since it's been requested to malloc an obscene amount of memory, but I can't see where a write to unmanaged memory occurs.

Can anyone shed some light on this?
Comments
1. By Anonymous Coward () on 2002-06-27 16:05
 
 looks like I screwed up the formatting
 The for loop looks like this
 =====
 
 for (i = 0; i 100) was the patch
2. By Anonymous Coward () on 2002-06-28 04:35
 
 While I haven't examined the code extensively, I think the patch does two things:
 
 1) Checking nresp <100 prevents a DoS, as you noted.
 
 2) If nresp is very large and unsigned, and if the value in nresp is later assigned to a signed variable, the signed variable may be negative when it should not be. Careful packet construction could cause a server to believe it's writing into a buffer when it's actually overwriting its stack or heap. Since I saw a lot of signed/unsigned cleanup commit messages around the time this vulnerability was announced, I think this is it.
3. By grendel () on 2002-06-29 08:38
 
 nresp * sizeof(char *) == 4 * (a large number).
 add in one part integer overflow, stir, and get a small number, happily malloced. the loop below then proceeds to use the large value and run willy-nilly over memory.
 
 like theo said, it's a kinda new class of vulnerability. everyone knows ints overflow. they don't know that can be bad. :(
By Anonymous Coward () on 2002-06-28 14:39

hmm write the services in C# .net using the CLR and MSIL. thats not a troll - its just its not vulnerable and is JIT compiled and cached.

(btw .net ISNT just for MS ;).
Comments
1. By Anonymous Coward () on 2002-06-28 17:49
  
  Actually, .net is only for M$. Ximian is wrking on Mono, but that's just the CLR.
  I no of no advantages of .net over Java/JVM. You can get Scheme, Ada, Python, and litterlally over one hundered other language compilers/interpreters tagreted at/running in JVM byte code. Sun might not be that great, but they beat teh crap out of M$ for my security dollar.

Latest Articles

Tue, Sep 10
- 05:39 Game of Trees 0.103 released (0)
Sun, Aug 25
- 09:13 rpki-client 9.2 released (0)
Sat, Aug 24
- 11:46 No unmodified files remain from original import of OpenBSD (0)
Wed, Aug 14
- 20:39 Game of Trees 0.102 released! (0)
- 05:31 The BSDCan 2024 Playlist is now complete (0)
Thu, Aug 08
- 09:26 OpenBSD -current moves to 7.6-beta (1)
Mon, Jul 29
- 12:27 Possible future vmm(4)/vmd(8) on arm64 (1)
Sat, Jul 27
- 11:05 UDP parallel input committed to -current (0)
Wed, Jul 24
- 05:28 Incoming: UDP parallel input (1)

Credits

Copyright © 2004-2008 Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to April 2nd 2004 as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]