New FreeBSD, NetBSD Security Advisories

Dan writes "FreeBSD has formally announced a security advisory entitled "OpenSSH buffer management error" for the now famous OpenSSH advisory (OpenSSH has released a new version 3.7.1 to address this issue). NetBSD has issued a similar advisory and fix for this issue. NetBSD has released two additional security advisories entitled "Kernel memory disclosure via ibcs2" and "Insufficient argument checking in sysctl(2)"."

Comments

Patches vs. Fixes

[Dancin_Santa]

If you ever take a look at the patched code for one of these security advisories, you mainly see some special case code stuck in there to patch up the problem. You never see a reconsideration of the problem. I wonder how long it takes to go from a release version through patch after patch until a piece of code is just old and crufty and in need of wholesale replacement.

Re:Patches vs. Fixes

[Horny Smurf]

in this case, the problem was a bug rather than a design issue, so a 3-line code change is appropriate. I do agree that there is a lot of "special case" "fixes" that try to hide fundamental problems.

Re:Patches vs. Fixes

[Anonymous Coward]

If you ever take a look at the patched code for one of these security advisories, you mainly see some special case code stuck in there to patch up the problem.

If you ever take a look at the actual *problem*, you'll find that hey are usually just buffer overflows or other unchecked data, in which case 'some special case code' is the only appropriate course of action.

I'll tell you what's REAL BSD news

[Anonymous Coward]

The first comment on a BSD story wasn't a BSD troll, now that my freinds is news for nerds, stuff that matters.

OS X

[Zelet]

Does this affect OS X's implementation of SSHD? So far Apple has not released a patch.

Re:OS X

[dthable]

I'm running 10.2.6 and I have OpenSSH 3.4p1. So yes, we are at risk.

Check your system. In terminal type:

sshd -v

Re:OS X

[endx7]

The lazy answer is, does mac OS X use openssh? If so, then it most likely would (since as far as I can tell, this is an openssh-only problem).

Re:OS X

[dthable]

It does use OpenSSH, but the desktop version has it disabled by default. If you really wanted to, you can grab the code, compile and install it yourself.

Just Remember

[rudy_wayne]

Having to fix a security flaw in a closed source program is proof than closed source is bad. Fixing a security flaw in an open source program is proof that open source is good.

Re:deceit.

[zulux]

Given that the default install has ssh turned on, will they change it to "two remote holes" ?

If you look carefully at the bug - at first glance, it lookls like when SSHD faluts out, some extra memory will be wiped with nulls.

Perhaps there's more to this but basically whats is going on

SSHD need more memory.
Memrory counter is added to.
Memeory is allocated.
Repeat (until memory allocation fails)

then...

Because SSHD needs to wipe all it's memory to null so no crpto stuff is left lying around, all the memory pointed to my them memory counter is wiped. But unfortunalty some of that memory doesen't belong to SSHD because the memory allocation failed.

So what?

[pbrammer]

All of the other vendors released similar bulletins... Most of them questioned the validity of this hole, but to be safe, they issued these notes to their customers to update OpenSSH. I know RedHat and Mandrake did.

Phil

Re:So what?

[MavEtJu]

It wasn't so much an exploit but more a denial of service.

If there is a way for third parties to disable a service running on my computer, yes I would like to be informed by it :-)

linux sucks donkey dick

[Horny Smurf]

I downloaded the OpenSSH 3.6 port for FreeBSD last night. It included the buffer overflow fix (which confused me, since I was planning on doing the patching myself :)

Of course, it installed sshd in /usr/local/sbin... sshd 2.9 (i think) was still located in /usr/sbin.

Re:linux sucks donkey dick

[akharon]

put
OPENSSH_OVERWRITE_BASE= true
in your /etc/rc.conf. I'll leave it to you to figure out what that does to the port...

Re:linux sucks donkey dick

[Not_Wiggins]

It also creates a startup file in /usr/local/etc/rc.d for you to use, if you wish.

No biggie... just disable the default invocation and rename the sshd.sh.example script in the above directory to sshd.sh.

What *I* found a little confusing is that everything I read stated I should be using 3.7.1, but they're providing a patched version of 3.6.1. 8/

Re:linux sucks donkey dick

[MavEtJu]

in your /etc/rc.conf

Make that /etc/make.conf

Re:deceit.

[sirket]

This isn't a hole on OpenBSD. According to Theo this can only crash SSHD, not give access.

-sirket

Re:deceit.

[Anonymous Coward]

If someone could get remote access to an OpenBSD system but the only thing they could do was shut down a service (let's say SSHD) I'd have to think that would be considered a hole.

But if someone can just crash it remotely without even getting to a shell it's not a hole? That doesn't makes sense to me.

I run OpenBSD on a home made firewall at home and I love it as much as the next guy, but I don't see how this can't be considered a hole.

Also remember

[BoomerSooner]

It is significantly easier for hackers to find exploits in programs that come with the source. This vunerability could have been exploited for 6 months or more. Being closed source has nothing to do with being able to fix security flaws. It does however mean that only the company/person who has the code can fix it.

There are security flaws in all software (maybe with the exception of Hello, World!), this has nothing to do with the availability of the source.

Actual Question...

[agent dero]

I was having problems the day before last, and I updated the SSH program to OpenSSH to fix some other problems, how might I find out if the version I installed had the fixer-upper in it? (and not by getting hacked :-p)

Hey give us trolls a chance

[Anonymous Coward]

We only come out at night...

for FreeBSD 4.8

[ubiquitin]

Hi there fellow slashdaughters, this got me upgraded:

./configure --prefix=/opt --sysconfdir=/etc/ssh
make
make install

use ps -aux to find the ##### of the process of sshd.

kill -HUP #####



Anyone who reboots to accomplish this upgrade shouldn't be a sysadmin. Have fun!

Re:for FreeBSD 4.8

[MavEtJu]

congratulations, you just have let your old sshd reread its configuration instead of stopping it and starting the new one.

Re:for FreeBSD 4.8

[ubiquitin]

Not sure why your comment got moderated up so high, since it might confuse people. Something not mentioned in the parent post that might make things a little clearer is that you'll want to replace the prefix path:
--prefix=/opt
with whatever is appropriate for your setup. Do a which sshd to find out where your sshd has been installed. What I ended up using on my FreeBSD 4.8 box was actually --prefix=/usr

Last but not least, if you've done much lock-down or modifications to your sshd_conf, you'd actually want to be using the original configuration instead of a new default one. Hope that helps.

Re:for FreeBSD 4.8

[Shanep]

Not sure why your comment got moderated up so high, since it might confuse people.

I think he is refering to the kill -HUP #####

Which will send the currently running ssh daemon the hangup signal, instructing it to re-read its configuration.

I think it is you who will be doing the confusing.

Anyone who reboots to accomplish this upgrade shouldn't be a sysadmin.

What an absolutely absurd statement. I bet you've just recently figured that you can upgrade a daemon without rebooting, so anyone who upgrades one and reboots cannot be as good as you?

Grow up.

BTW, if you kindly give me your IP address, I will gladly (from one friendly BSD user to another) provide you with a security audit free of charge. I'm sure with your leet skillz, I will be able to give you a glowing report. (psstt, hey, I'll give you a tip first, kill and restart your sshd properly before you give me that IP! If you can't figure out how to do that, just give your machine a reboot).

Wanker.

Re:for FreeBSD 4.8

[Shanep]

Which will send the currently running ssh daemon the hangup signal, instructing it to re-read its configuration.

Since processes decide themselves what they should do with a hangup signal, in this case I am wrong...

http://www.openbsd.org/cgi-bin/man.cgi?query=sshd

Your attitude still needs some adjustment though.

Re:deceit.

[R.Caley]

[...]But if someone can just crash it remotely without even getting to a shell it's not a hole? That doesn't makes sense to me.

The difference is that if they could get even a very limited shell, that would turn all the local exploit bugs into potential remote exploit holes. That is clearly an order of magnitude more dangerous than a simple DOS.

So, I think it makes sense to distinguish between the two cases, though I think just talking about `holes' is silly. Didn't they used to have `remote root exploit' or similar wording in there? Perhaps the PHBs didn't understand.

Re:deceit.

[pooh666]

You can get your ass dos attacked, or you could get a dos attack your DNS servers and no one has to log in. Your logic is very weak.

Re:deceit.

[tedu]

you can crash *your* sshd on the server. not the parent. so your connection closes, and everyone else's stays there, and the parent keeps listening for more.

stop this

[meshko]

I can't stand it when Dan posts stories about FreeBSD with links to his bsdforums site. This is so useless. The link should go to the mailing list archive or a web site with the advisory, not to the discussion of it on your site.
Dan, please don't do it! Please! It looks really bad.

Copy/Paste Trolls

[nurb432]

Gotta love them, zero originality.