Welcome to the MacNN Forums.

WJMoore · Jun 25, 2002, 05:51 AM

Users of SSH in OS X (which is OpenSSH) should probably keep an eye on what comes of this upcoming OpenSSH vulnerability.

<a href="http://www.mindrot.org/pipermail/openssh-unix-announce/2002-June/000041.html" target="_blank">http://www.mindrot.org/pipermail/openssh-unix-announce/2002-June/000041.html</a>

Wesley

ramseyp · Jun 25, 2002, 12:40 PM

Macintouch has a reader note on how to render the exploit "unexploitable."

Here's what I've done based on that article:

Launch NetInfo Manager.

Create a user named sshd.

Create a group sshd and add the user sshd to the group.

Save and update, then quit NetInfo Manager.

Download the portable version of OpenSSH 3.3p1 to the desktop. The file will be named openssh-3.3p1.tar.gz.

Open the terminal.
<blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;">
sudo mkdir /var/empty

sudo chmod 755 /var/empty

cd ~/Desktop/

tar-xzf openssh-3.3p1.tar.gz

cd openssh-3.3p1/

./configure --with-privsep-path=/var/empty --with-privsep-user=sshd

make

sudo make install</pre><hr /></blockquote>Open System Preferences and go to Sharing.

Click on the tab for Application.

Uncheck "Allow remote login" and then check it again.

DominikHoffmann · Jun 25, 2002, 03:46 PM

<blockquote>quote:<hr />Originally posted by ramseyp:
<blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;">
./configure --with-privsep-path=/var/empty --with-privsep-user=sshd</pre><hr /></blockquote><hr /></blockquote>This configuration aborts with the following lines: <blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;">checking whether OpenSSL's headers match the library... no
configure: error: Your OpenSSL headers do not match your library</pre><hr /></blockquote>My system is at 10.1.5. What could be wrong? Would I have to update my OpenSSH library, as well?

bleee · Jun 25, 2002, 04:28 PM

<blockquote>quote:<hr />Originally posted by DominikHoffmann:
 <blockquote>quote:<hr />Originally posted by ramseyp:
<blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;">
./configure --with-privsep-path=/var/empty --with-privsep-user=sshd</pre><hr /></blockquote><hr /></blockquote>This configuration aborts with the following lines: <blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;">checking whether OpenSSL's headers match the library... no
configure: error: Your OpenSSL headers do not match your library</pre><hr /></blockquote>My system is at 10.1.5. What could be wrong? Would I have to update my OpenSSH library, as well?<hr /></blockquote>I get that message with just running ./configure been trying all day to figure out what was wrong haven't found and answer yet. Does anyone know if Apple will release something?

rantweasel · Jun 25, 2002, 07:18 PM

<blockquote>quote:<hr />Originally posted by DominikHoffmann:
[QUOTE]Originally posted by ramseyp:
<blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;">checking whether OpenSSL's headers match the library... no
configure: error: Your OpenSSL headers do not match your library</pre><hr /></blockquote>My system is at 10.1.5. What could be wrong? Would I have to update my OpenSSH library, as well?<hr /></blockquote>Indeed. Take a look at me mac.com page, I have a set of instructions that I've used to keep myself even with the current version of OpenSSH, regardless of how long Apple dawdles. This is not the first time there's been a new version of OpenSSH without an immediate Apple update - OpenSSH packages should be a matter of hours to prepare & test after a new version is released!

Oh, and here's <a href="http://homepage.mac.com/~rantweasel/openssh-upgrade.html" target="_blank">the page.</a>

rantweasel · Jun 25, 2002, 07:31 PM

<blockquote>quote:<hr />Originally posted by ramseyp:
Macintouch has a reader note on how to render the exploit "unexploitable."
<hr /></blockquote>First of all, it's unclear whether priviledge separation works on OS X, and second, the bug still exists in OpenSSH 3.3, if you read the advisory. If privsep works, it will help in dealing with the hole, but whether it renders it unexploitable is also unclear. It would be A REALLY GOOD IDEA to keep monitoring the <a href="http://www.openssh.org" target="_blank">OpenSSH page</a> for further status updates, and to patch OpenSSH again once they have released 3.4, which is due out next week to deal with the upcoming bug announcement.

DominikHoffmann · Jun 26, 2002, 03:14 AM

<blockquote>quote:<hr />Originally posted by rantweasel:
Indeed. Take a look at my mac.com page, I have a set of instructions that I've used to keep myself even with the current version of OpenSSH, regardless of how long Apple dawdles. This is not the first time there's been a new version of OpenSSH without an immediate Apple update - OpenSSH packages should be a matter of hours to prepare & test after a new version is released!

Oh, and here's <a href="http://homepage.mac.com/~rantweasel/openssh-upgrade.html" target="_blank">the page.</a><hr /></blockquote>Thank you so much! You really know your stuff!

ramseyp · Jun 26, 2002, 09:54 AM

Sorry,

Forgot to mention that the developer's tools and OpenSSL should be installed. I'd installed the Dev tools so long ago it slipped my mind. Rantweasel's page mentions them in the third paragraph. Good page. BTW.

Another good site for Unix tools on Mac OS X (Apache, TCP headers, OpenSSH) is <a href="http://www.stepwise.com" target="_blank">Stepwise</a>.

absmiths · Jun 26, 2002, 12:15 PM

Another solution to upgrading your system is mentioned in the advisory:

<blockquote>quote:<hr />3. Short-Term Solution:

Disable ChallengeResponseAuthentication in sshd_config.

or

Enable UsePrivilegeSeparation in sshd_config.<hr /></blockquote>We can't trust UsePrivilegeSeparation, but we can disable ChallengeResponseAuthentication, which is what I did. Just check your /etc/sshd_config file - there is a line to uncomment that will do this. If you don't use s/key passwords (as I don't) then this is as good as upgrading (for this particular vulnerability). I disabled it and my shells still work as before.

BTW, I have 2 OS X machines, but I only made this change to the one that is accessible through the firewall - the second machine is not vulnerable since the first would have to be compromised to get to it.

rantweasel · Jun 26, 2002, 05:11 PM

<blockquote>quote:<hr />Originally posted by DominikHoffmann:
Thank you so much! You really know your stuff!<hr /></blockquote>Don't thank me quite yet. I just realized that I need to add a section on adding the sshd user in order to get privsep working properly. If you follow my instructions without adding the sshd user, you'll get errors when you try to start sshd. That's only a problem with privsep enabled, though. Also, FYI for everyone, OpenSSH 3.4 was released today, with a lot of security and bug fixes, so even if you already upgraded to 3.3, now's a really good time to upgrade OpenSSH.

Chas · Jun 26, 2002, 05:15 PM

<blockquote>quote:<hr />Originally posted by ramseyp:
Macintouch has a reader note on how to render the exploit "unexploitable."

Here's what I've done based on that article:

Launch NetInfo Manager.

Create a user named sshd.

Create a group sshd and add the user sshd to the group.

Save and update, then quit NetInfo Manager.

Download the portable version of OpenSSH 3.3p1 to the desktop. The file will be named openssh-3.3p1.tar.gz.

Open the terminal.
<blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;">
sudo mkdir /var/empty

sudo chmod 755 /var/empty

cd ~/Desktop/

tar-xzf openssh-3.3p1.tar.gz

cd openssh-3.3p1/

./configure --with-privsep-path=/var/empty --with-privsep-user=sshd

make

sudo make install</pre><hr /></blockquote>Open System Preferences and go to Sharing.

Click on the tab for Application.

Uncheck "Allow remote login" and then check it again.<hr /></blockquote>Hey, I did all this (and I previously installed my OpenSSL headers), but it errored out at the "sudo make install". Even though I have a user "sshd" and group "sshd" setup in NetInfo, it gives me the error:

/usr/local/etc/ssh_host_key already exists, skipping.
/usr/local/etc/ssh_host_dsa_key already exists, skipping.
/usr/local/etc/ssh_host_rsa_key already exists, skipping.
id sshd || \
echo "WARNING: Privilege separation user \"sshd\" does not exist"
uid=502(sshd) gid=20(staff) groups=20(staff) 24(sshd)

Could you tell me what settings exactly that you used for user and group "sshd" in NetInfo?

das · Jun 26, 2002, 05:17 PM

FYI, just received this response from Apple Product Security:

From: Product Security <[email protected]>
Date: Wed Jun 26, 2002 03:41:59 PM US/Central
To: Dave Schroeder <[email protected]>
Subject: Re: Upcoming OpenSSH vulnerability

We're planning to release an update that addresses the Apache and OpenSSH vulnerabilities.

On Tuesday, June 25, 2002, at 07:05 AM, Dave Schroeder wrote:

There is an upcoming OpenSSH vulnerability that you should be aware of:

From <a href="http://www.mindrot.org/pipermail/openssh-unix-announce/2002-June/000041.html" target="_blank">http://www.mindrot.org/pipermail/openssh-unix-announce/2002-June/000041.html</a>

[ 06-26-2002, 05:19 PM: Message edited by: das ]

ramseyp · Jun 27, 2002, 12:45 PM

Ugh,

I'm addlepated about this now. i didn't get an error installing 3.3, but I do get it installing 3.4.

echo "WARNING: Privilege separation user \"sshd\" does not exist"
uid=4294967293(sshd) gid=4294967293(sshd) groups=4294967293(sshd)

It happens after doing the "sudo make install" comand. In netinfo, I have a user "sshd" with:

name: sshd
uid: -3
gid: -3
shell: /bin/false
home: /var/empty

and I have a group "sshd" with:

name: sshd
gid: -3
users: sshd

I do not know where I am going wrong on this.

ramseyp · Jun 27, 2002, 12:48 PM

Curious: There's a user nobody in Netinfo. Could you assign that to be the privsep user? and /dev/null as the path?

Hrmm...

DominikHoffmann · Jun 27, 2002, 01:04 PM

<blockquote>quote:<hr />Originally posted by ramseyp:
<blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;"> echo "WARNING: Privilege separation user \"sshd\" does not exist"
uid=4294967293(sshd) gid=4294967293(sshd) groups=4294967293(sshd)</pre><hr /></blockquote><hr /></blockquote>I encountered the same problem. Maybe rantweasel can help.

Seeing ramseyp's large uids and gids, I looked at mine. My uid was similarly large, because I hadn't added a uid property to the sshd users. I changed that and made it a more reasonable number. Nonetheless, I get very similar output:
<blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;"> echo "WARNING: Privilege separation user \"sshd\" does not exist"
uid=7799(sshd) gid=2109(sshd) groups=2109(sshd)</pre><hr /></blockquote>The user clearly exists as I can see in Netinfo: <blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;">[localhost:~/Unix/OpenSSH 3.4p1/openssh-3.4p1] admin% niutil -read . /users/sshd

name: sshd
gid: 2109
passwd: *
home: /var/empty
shell: /dev/null
uid: 7799</pre><hr /></blockquote>

rantweasel · Jun 28, 2002, 09:00 PM

<blockquote>quote:<hr />Originally posted by DominikHoffmann:
I encountered the same problem. Maybe rantweasel can help.
<snip a wee bit>
<blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;">[localhost:~/Unix/OpenSSH 3.4p1/openssh-3.4p1] admin% niutil -read . /users/sshd

name: sshd
gid: 2109
passwd: *
home: /var/empty
shell: /dev/null
uid: 7799</pre><hr /></blockquote><hr /></blockquote>Well, here's what I've got:

<blockquote>code:<hr /><pre style="font-size:x-small; font-family: monospace;">mwegner@itachi /usr/local/openssh-3.4p1>sudo niutil -read . /users/sshd
uid: 27
name: sshd
home: /var/empty
shell: /sbin/nologin
gid: 27
mwegner@itachi /usr/local/openssh-3.4p1>sudo niutil -read . /groups/sshd
passwd: *
name: sshd
users: sshd
gid: 27</pre><hr /></blockquote>It's working perfectly for me, for 3.3p1 and 3.4p1, and privsep is working 100% I would suggest using positive integers less than 1000 for uid and gid, since it looked like using negative numbers was getting some sort of overflows (in ramseyp's case). Now, just to clarify, is that an error when you try to run sshd, or is it part of the make install? If it's part of the make install, I believe that it may be a script or Makefile error, and you should try running sshd just to check.

Good luck, and let me know what happens.

DominikHoffmann · Jun 29, 2002, 09:51 AM

OpenSSH 3.4p1 is installed by the Security Update July 2002 in Software Update. I'm going to revert the links that rantweasel suggested installing before I run the update.

Jerry Brown · Jun 30, 2002, 03:49 PM

<blockquote>quote:<hr />Originally posted by DominikHoffmann:
OpenSSH 3.4p1 is installed by the Security Update July 2002 in Software Update. I'm going to revert the links that rantweasel suggested installing before I run the update.<hr /></blockquote>I installed the Security Update, and it does not appear to be using Privilege Separation. My sshd_config file has not been modified, nor has an sshd user or group been created. Anyone have any idea as to what the various config parameters were for the Update?

petej · Jun 30, 2002, 05:06 PM

<blockquote>quote:<hr />Originally posted by Jerry Brown:
I installed the Security Update, and it does not appear to be using Privilege Separation.<hr /></blockquote>That's OK. While PrivSep mitigates the bug, 3.4p1 actually fixes it, so PrivSep is just icing.

petej · Jun 30, 2002, 05:14 PM

<blockquote>quote:<hr />Originally posted by ramseyp:
Curious: There's a user nobody in Netinfo. Could you assign that to be the privsep user? and /dev/null as the path?<hr /></blockquote>If you're paranoid enough about security to want privilege separation, then you're sufficiently paranoid to want the privsep user to be a completely separate entity, with it's own empty directory. If you use an existing user, than future compromises can take over the user, so if you run your webserver as nobody, then an sshd compromise can provide an entree to your webserver.

Jerry Brown · Jun 30, 2002, 07:47 PM

<blockquote>quote:<hr />Originally posted by petej:
 <blockquote>quote:<hr />Originally posted by Jerry Brown:
I installed the Security Update, and it does not appear to be using Privilege Separation.<hr /></blockquote>That's OK. While PrivSep mitigates the bug, 3.4p1 actually fixes it, so PrivSep is just icing.<hr /></blockquote>True, but privsep does lessen chance of future, heretofor unknown, nasties from becoming disasters. The whole concept makes sense, and I'm surprised to see it wasn't implemented for the Update.