[t_hah]

http://slashdot.org/articles/03/09/1...26&tid=172

[mishap]

Originally posted by t_hah:
http://slashdot.org/articles/03/09/1...26&tid=172

i would think it would affect you if SSH was on. I'm sure there will be a patch by the end of the week.

[smeger]

Unfortunately, I believe that this does affect us. To secure yourself, open /Applications/System Preferences, navigate to Sharing, and turn off Remote Login.

SSH is widely used, so I'm sure Apple will have a patch really quickly. Once they do, it's safe to turn this back on, assuming you actually need & use it.

[fortepianissimo]

Originally posted by t_hah:
http://slashdot.org/articles/03/09/1...26&tid=172

Definitely YES - turn off your Remote Login asap! If you use ssh from Fink, do a

daemonic disable ssh

and

ps ax | grep sshd

and

kill -9 <sshd pid>

[justinkim]

Originally posted by mishap:
i would think it would affect you if SSH was on. I'm sure there will be a patch by the end of the week.

I certainly hope that we have it before the end of the week. I've been keeping an eye on the openssh mirror sites and plan on compiling/reinstalling openssh as soon as 3.7 is released.

[Millennium]

OSX uses a different version of SSH, which may or may not be vulnerable to this hole. At the moment, I'm not sure.

Therefore, it's best to play it safe and assume that we are vulnerable. Apple will likely release either a press release or an update, within the next day or so, depending on whether we're vulnerable or not.

[Arkham_c]

The vulnerability is in 3.6p1. OSX is running OpenSSH_3.4p1. I don't know if the problem is in older releases.

There is a patch to buffer.c which purports to solve the problem. I am looking for it now.

The current buffer.c has not changed in a long time (see CVSWEB for the changelog), so I suspect that we are affected.

[edit:fixed a typo]

[Arkham_c]

Ok, I found the patch. See here:

CVS Patch for OpenSSH

[diamondsw]

Since this is a root exploit, does it affect us if we simply disable the root account? I'd like to keep SSH up for other authenticated users, if possible.

[fortepianissimo]

Originally posted by Arkham_c:
The vulnerability is in 3.6p1. OSX is running OpenSSH_3.4p1. I don't know if the problem is in older releases.

There is a patch to buffer.c which purports to solve the problem. I am looking for it now.

The current buffer.c has not changed in a long time (see CVSWEB for the changelog), so I suspect that we are affected.

[edit:fixed a typo]

1. this affects to all versions previous to 3.7

2. I run RedHat 8 and the OpenSSH there was 3.4p1 - it just got patched a few hours ago by RedHat.

[proton]

OK. This is easy folks. Mac OS X is affected by the bug, as to whether it is exploitable on Mac OS X, that we don't know. Assume it is unless we find out otherwise.

The patch to fix all the security problems fixed in OpenSSH 3.7.1, grab this patch (note that this is only for people who like compiling their own SSH, for everyone else, turn off remote login and wait for Apple's software update).

ftp://ftp.openbsd.org/pub/OpenBSD/pa...shbuffer.patch

- proton

[justinkim]

Also for those inclined to build their own SSH, Openssh 3.7 is starting to appear on the Openssh mirror sites.

Visit http://www.openssh.org for more information.

[moki]

The other thing to keep in mind is that this type of exploit allows for the insertion of malicious code... but that code will be x86 code

In other words, odds are very good that in the rare event that your machine is attacked in this manner, and it is running sshd, the code injected via the buffer overflow will do nothing other than cause sshd to crash.

Let's hear it for the minority ISA!

[Simon]

I would like to quote diamondsw, because I think he has a very important question. Does anybody have an answer?

Since this is a root exploit, does it affect us if we simply disable the root account?

I'd prefer just disabling root than ssh altogether.

[proton]

Since this is a root exploit, does it affect us if we simply disable the root account?

Yes it would still affect you. Part of the ssh daemon runs as root regardless of if the root account is "enabled" for login..

- proton

[Simon]

Originally posted by proton:
Yes it would still affect you. Part of the ssh daemon runs as root regardless of if the root account is "enabled" for login

Proton, thanks for that info. I guess I'll keep sshd off until the patch arrives.

[theolein]

Originally posted by moki:
The other thing to keep in mind is that this type of exploit allows for the insertion of malicious code... but that code will be x86 code

In other words, odds are very good that in the rare event that your machine is attacked in this manner, and it is running sshd, the code injected via the buffer overflow will do nothing other than cause sshd to crash.

Let's hear it for the minority ISA!

Word up! Buffer overrun exploits that inject malicious code have to use machine language (i.e. x86, ppc, sparc etc) in order to work. 99% of all exploits will be for x86 machines (the person writing the exploit would need to have access to a PPC machine in order to test it for the Mac), x86 machines being the vast majority.

However, playing it safe and deactivating sshd is a good idea. You never know when some troubled individual, who's angry and SJ for introducing new Powerbooks just after he bought an older model, goes on the rampage on the net.

[smeger]

It's true that most buffer exploits written will be on x86 assembly. But apple.slashdot.org posted a link to a bunch of PPC exploit code ready and waiting for a buffer to exploit two weeks ago.

I compiled a few of the examples to see how they work, and they did what they said they did.

If someone had a working x86 exploit, it would be pretty trivial to mod it to be a PPC exploit using these posted sources. Like, it would involve copy and paste and that's about it.

Here is the link I'm talking 'bout.

[diamondsw]

Originally posted by proton:
Yes it would still affect you. Part of the ssh daemon runs as root regardless of if the root account is "enabled" for login..

- proton

Thanks! However, I have a further question. How would this allow someone to hack an OS X box? As was pointed out, they can't login (if you have root disabled), and they most likely will not be trying to run PPC code, but x86 code. So what exactly is the danger to an OS X user?

Don't get me wrong - I have disabled SSH just to be safe and await the patch from Apple. I'm just curious as to the real impact this has on Mac users.

[fortepianissimo]

Originally posted by diamondsw:
Thanks! However, I have a further question. How would this allow someone to hack an OS X box? As was pointed out, they can't login (if you have root disabled), and they most likely will not be trying to run PPC code, but x86 code. So what exactly is the danger to an OS X user?

Don't get me wrong - I have disabled SSH just to be safe and await the patch from Apple. I'm just curious as to the real impact this has on Mac users.

How about creating a secret account, or even running a secret server (with root previlege), like a command shell?

[Arkham_c]

Originally posted by diamondsw:
Thanks! However, I have a further question. How would this allow someone to hack an OS X box? As was pointed out, they can't login (if you have root disabled), and they most likely will not be trying to run PPC code, but x86 code. So what exactly is the danger to an OS X user?

Disabling root for login is not at issue. Let me give an example. You have sshd (the ssh daemon) running as root on your system. This process has the root userid and thus can do things requiring root priveleges.

Now, when you buffer overflow this program, you do so within the program's process memory space. You then inject some compiled PPC byte code to open a shell. You then point the program stack pointer at this code, which causes the code to execute. Voila, you are running a root shell and the host owner is in trouble.

[theolein]

Originally posted by smeger:
It's true that most buffer exploits written will be on x86 assembly. But apple.slashdot.org posted a link to a bunch of PPC exploit code ready and waiting for a buffer to exploit two weeks ago.

I compiled a few of the examples to see how they work, and they did what they said they did.

If someone had a working x86 exploit, it would be pretty trivial to mod it to be a PPC exploit using these posted sources. Like, it would involve copy and paste and that's about it.

Here is the link I'm talking 'bout.

I read the slashdot article. I wish those hackers looking for lone ppc boxes with running sshd processes in the x86 jungle lots of luck

[moki]

Originally posted by smeger:
It's true that most buffer exploits written will be on x86 assembly. But apple.slashdot.org posted a link to a bunch of PPC exploit code ready and waiting for a buffer to exploit two weeks ago.

I compiled a few of the examples to see how they work, and they did what they said they did.

If someone had a working x86 exploit, it would be pretty trivial to mod it to be a PPC exploit using these posted sources. Like, it would involve copy and paste and that's about it.

...and then they'd have to be sure what platform their target was and inject the right ISA depending on that platform.

Not saying it isn't possible using something like nmap, but it isn't likely. Most of these exploits are wrapped in scripts that just try every host they can find, and report back the ones they rooted. I highly doubt people would go to the trouble to add ISA detection (not an easy task) as well.

Sure, it's possible a lone hacker could target you specifically -- but I'm not aware of there being any reports of these exploits actually being in the wild, they were just listed as potential exploits, and were fixed.

So yes, if you want to be completely, utterly safe, turn Remote Login off. I'm not too concerned, though.

[osiris]

Lots of interesting info here.
Thankfully we are a minority with respect to the virus attacks, but what about hacking?
Is OS X hard to hack into? Anyone ever try?

I'm just curious if we have some other vulnerablity that we don't know about.

[smeger]

Originally posted by moki:
...and then they'd have to be sure what platform their target was and inject the right ISA depending on that platform.

Of course, if there is a working x86 exploit and your Mac gets targeted, the service will crash when it tries to execute the x86 code thinking it's PPC machine language. Which is also a bad result...

Anyway, I'm not trying to say that it's super-likely that there are legions of überhackers targetting people's OS X boxes with massively sophisticated hax. But I am trying to say that it wouldn't be too difficult to take an existing x86 exploit, mod it to become a PPC exploit, and use it to target a known OS X box, thus gaining the code to Escape Velocity from Moki's development machine.

Just kidding, of course. My point is simply that this is an issue, even if probability of exploit is low. I've turned off SSH on all of my boxes (and told everyone I know to turn it off), and will leave things that way until Software Update patches me up.

P.S. Didn't mean to cause any offense with my hacking example, Moki. Hope you didn't take any.

[absmiths]

Originally posted by moki:
...and then they'd have to be sure what platform their target was and inject the right ISA depending on that platform.

Not saying it isn't possible using something like nmap, but it isn't likely. Most of these exploits are wrapped in scripts that just try every host they can find, and report back the ones they rooted. I highly doubt people would go to the trouble to add ISA detection (not an easy task) as well.

Sure, it's possible a lone hacker could target you specifically -- but I'm not aware of there being any reports of these exploits actually being in the wild, they were just listed as potential exploits, and were fixed.

So yes, if you want to be completely, utterly safe, turn Remote Login off. I'm not too concerned, though.

Yes, unfortunately some of us depend on it on a daily basis (I can't drive across the country that often) and need to leave it enabled.

When will these stupid buffer overruns ever end? There are only about 1,000,000 more of these exploits waiting to be found if this continues.

[gatorparrots]

Originally posted by osiris:
Lots of interesting info here.
Thankfully we are a minority with respect to the virus attacks, but what about hacking?
Is OS X hard to hack into? Anyone ever try?

Yes.
http://freaky.staticusers.net/ugboar...forum.php?f=15

[Gul Banana]

Originally posted by gatorparrots:
Yes.
http://freaky.staticusers.net/ugboar...forum.php?f=15

That forum is very.. amusing. I don't think we need to worry about the people there.

[Michel Fortin]

Originally posted by absmiths:
When will these stupid buffer overruns ever end? There are only about 1,000,000 more of these exploits waiting to be found if this continues.

When the ssh deamon will be rewritten in Java.

[proton]

And the Java engine is entirely bug free...

- proton

[Partisan01]

Originally posted by Michel Fortin:
When the ssh deamon will be rewritten in Java.

I can't wait for the days of java ssh, a 5 minute load up time, a half hour to computer your key....having to install 500megs worth of libraries from sun to find the installation failed...

[waffffffle]

Originally posted by Michel Fortin:
When the ssh deamon will be rewritten in Java.

So that one byte-code version of the exploit can successfully attack different platforms?

[gatorparrots]

Originally posted by Gul Banana:
That forum is very.. amusing. I don't think we need to worry about the people there.

http://www.undergroundmac.com/hacking.html
or, perhaps more "legit":
https://doris.scriptkiddie.net/PPC_Stuff/

The point being, there are people out there writing tools and developing and testing exploit code. This is happening and it is something of concern for any sysadmin.

[Gul Banana]

Originally posted by gatorparrots:
http://www.undergroundmac.com/hacking.html
or, perhaps more "legit":
https://doris.scriptkiddie.net/PPC_Stuff/

The point being, there are people out there writing tools and developing and testing exploit code. This is happening and it is something of concern for any sysadmin.

That's true - especially the second link, which you could very easily combine with the sshd exploit. My original point remains, though, about freaky.staticusers.net.