Upcoming OpenSSH vulnerability
Corinna Vinschen
> On Mon, Jun 24, 2002 at 03:00:10PM -0600, Theo de Raadt wrote:
> > However, I can say that when OpenSSH's sshd(8) is running with priv
> > seperation, the bug cannot be exploited.
I hope that you're working on getting that bug fixed also for
systems which aren't able to support privsep due to system constraints.
The Cygwin version of OpenSSH can't support it since sendmsg()/recvmsg()
currently can't transmit file descriptors.
Can we expect a bug fix which helps also for non-privsep'd sshds?
Corinna
--
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vins...@redhat.com
_______________________________________________
openssh-...@mindrot.org mailing list
http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
Niels Provos
> The Cygwin version of OpenSSH can't support it since sendmsg()/recvmsg()
> currently can't transmit file descriptors.
mmap. File descriptor passing is required only for
post-authentication privilege separation.
Niels.
Corinna Vinschen
> On Tue, Jun 25, 2002 at 10:34:33AM +0200, Corinna Vinschen wrote:
> > The Cygwin version of OpenSSH can't support it since sendmsg()/recvmsg()
> > currently can't transmit file descriptors.
> You still get pre-authentication privilege separation if you support
> mmap. File descriptor passing is required only for
> post-authentication privilege separation.
Yep, I've already released a new version of OpenSSH (3.3p1-2) as
part of the Cygwin net release containing Markus' fix to suppress
postauth privsep.
Corinna
--
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vins...@redhat.com
Douglas E. Engert
upcomming OpenSSH vulnerability will be to run OpenSSH-3.3 with the Privilege
Separation enabled.
This scares the daylights out of me! Think about what you are doing here.
(1) OpenSSH 3.3 with the privsep code has been only out for less then a week.
(2) Its hundreds of lines of code.
(3) The privsep does not run on all platforms
(4) The privsep does not work with all the features in current ssh.
(5) The privsep code has SSHD using here-to-for unused operating system features.
(6) People with local modifications to SSH may not be able to
integrate them in such a short time frame.
Don't get me wrong, the privsep concept looks like a great idea, as a second
line of defense. But it should not be the primary defense.
A fix is needed for the original bug. You still need it to keep the hackers
off the machine. Saying that they are confined to the unprivileged child process
still lets then have access to cycles and the network where they can try and
attack the operating system and your network from inside.
The other aspect of this is the reliability of 3.3. With all the new code
what other problems might be introduced?
If you publish the problem, with out a real fix, and expect everyone to
implement 3.3 with privsep you will have a lot of people upset who can't run 3.3 or
can't run the privsep code. These people will be left out in the cold.
You need to provide a universal fix for all, not a partial fix for only some.
Thanks for listening.
--
Douglas E. Engert <DEEn...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Ben Lindstrom
On Tue, 25 Jun 2002, Douglas E. Engert wrote:
> >From all of the e-mail recently, it appears that the "solution" to the
> upcomming OpenSSH vulnerability will be to run OpenSSH-3.3 with the Privilege
> Separation enabled.
>
> This scares the daylights out of me! Think about what you are doing here.
>
> (1) OpenSSH 3.3 with the privsep code has been only out for less then a week.
>
Incorrect, 3.1 has Privsep.
> (2) Its hundreds of lines of code.
>
> (3) The privsep does not run on all platforms
>
If vendors would have started back in 3.1 helping us (over a month ago
now?) this would not be an issue.
> (4) The privsep does not work with all the features in current ssh.
>
What features? You have debugging information? Patches? Solutions? or
are you just blowing steam?
> (5) The privsep code has SSHD using here-to-for unused operating
>system features.
>
Umm.. you wish to clarify this babble?
> (6) People with local modifications to SSH may not be able to
> integrate them in such a short time frame.
>
> Don't get me wrong, the privsep concept looks like a great idea, as a second
> line of defense. But it should not be the primary defense.
>
> A fix is needed for the original bug. You still need it to keep the hackers
> off the machine. Saying that they are confined to the unprivileged child process
> still lets then have access to cycles and the network where they can try and
> attack the operating system and your network from inside.
>
Look at it this way. Do you want us to release the expliot and the patch
now? Or would you rather have us wait the few days to gather patch fixes
so hopefully 70% of those following along can at least be semiprotected?
This is the correct course of action. I agree with Theo's reasons 100%.
> The other aspect of this is the reliability of 3.3. With all the new code
> what other problems might be introduced?
>
You bothered to help us test? I've not seen a patch from you nor any
testing data? I'm starting to get sick and tired of people whining but
not doing one bit of useful work.
I hear it on bugtraq, I hear it on slashdot, and I hear it on #unix and
#unixhelp on efnet. Frankly. I'm starting to understand thy Theo and
other take the...
"Sit down, shutup and code." mindset.
> If you publish the problem, with out a real fix, and expect everyone to
> implement 3.3 with privsep you will have a lot of people upset who can't run 3.3 or
> can't run the privsep code. These people will be left out in the cold.
>
Privsep is a stopgap.... If you are stupid enough to think that we sould
leave an expliot around in our tree just because we don't want to publish
it. Your extremely wrong.
> You need to provide a universal fix for all, not a partial fix for only some.
>
You bothered to read the the announcement by Theo? THERE WILL BE A FIX.
However, we want to ensure we can get as many people to a semi-safe
position *BEFORE* every black hat in the gawd damn net gets their hands on
it.
Ain't that a good idea? =) Or would you rather have a hacker crack your
system before you even get a chance to patch it? Take your choice.
- Ben
Douglas E. Engert
that you and your group must be under a lot of presure at this time. So thanks for
taking the time to respond.
Ben Lindstrom wrote:
>
> On Tue, 25 Jun 2002, Douglas E. Engert wrote:
>
> > >From all of the e-mail recently, it appears that the "solution" to the
> > upcomming OpenSSH vulnerability will be to run OpenSSH-3.3 with the Privilege
> > Separation enabled.
> >
> > This scares the daylights out of me! Think about what you are doing here.
> >
> > (1) OpenSSH 3.3 with the privsep code has been only out for less then a week.
> >
> Incorrect, 3.1 has Privsep.
I am sorry, but I don't see it in the version I have: openssh-3.1p1.tar.gz
But that's a minor point.
>
> > (2) Its hundreds of lines of code.
> >
> > (3) The privsep does not run on all platforms
> >
> If vendors would have started back in 3.1 helping us (over a month ago
> now?) this would not be an issue.
Yes that would have been helpful.
>
> > (4) The privsep does not work with all the features in current ssh.
> >
> What features?
"Compression is disabled on some systems, and the many varieties of PAM are causing
major headaches." (From: Theo de Raadt <der...@cvs.openbsd.org> 6/24)
You have debugging information? Patches? Solutions? or
> are you just blowing steam?
No debuging yet, I just got 3.3 without privsep working today with GSSAPI.
I am going by what I have been reading in recent e-mails.
>
> > (5) The privsep code has SSHD using here-to-for unused operating
> >system features.
> >
> Umm.. you wish to clarify this babble?
This appears to be the first time SSH is using shared memmory, and the
passing of FDs.
>
> > (6) People with local modifications to SSH may not be able to
> > integrate them in such a short time frame.
> >
> > Don't get me wrong, the privsep concept looks like a great idea, as a second
> > line of defense. But it should not be the primary defense.
> >
> > A fix is needed for the original bug. You still need it to keep the hackers
> > off the machine. Saying that they are confined to the unprivileged child process
> > still lets then have access to cycles and the network where they can try and
> > attack the operating system and your network from inside.
> >
>
> Look at it this way. Do you want us to release the expliot and the patch
> now?
No, What I would like you to do is release the patch when it is ready. But correct
me if I am wrong, from all the e-mail about using privsep, I was worried that
it would be the solution. If you have a patch for the real problem, that would be great.
> Or would you rather have us wait the few days to gather patch fixes
> so hopefully 70% of those following along can at least be semiprotected?
>
> This is the correct course of action. I agree with Theo's reasons 100%.
>
> > The other aspect of this is the reliability of 3.3. With all the new code
> > what other problems might be introduced?
> >
>
> You bothered to help us test? I've not seen a patch from you nor any
> testing data? I'm starting to get sick and tired of people whining but
> not doing one bit of useful work.
Actually I have been very happy with the support of the OpenSSH,
and was trying to test this week with 3.3 with GSSAPI modifications
and Krb5-1.2.5 on Solaris, then HPUX, AIX, and SGI.
Unfortunatly the GSS code needs work if it is to be used with privsep. I have
been in touch with Simon Wilkinsonn on this.
That is my main concern. If the upcoming solution was to rely mainly on privsep,
then I have a major problem. Your comments imple that it will not.
>
> I hear it on bugtraq, I hear it on slashdot, and I hear it on #unix and
> #unixhelp on efnet. Frankly. I'm starting to understand thy Theo and
> other take the...
>
> "Sit down, shutup and code." mindset.
>
> > If you publish the problem, with out a real fix, and expect everyone to
> > implement 3.3 with privsep you will have a lot of people upset who can't run 3.3 or
> > can't run the privsep code. These people will be left out in the cold.
> >
>
> Privsep is a stopgap.... If you are stupid enough to think that we sould
> leave an expliot around in our tree just because we don't want to publish
> it. Your extremely wrong.
Thanks for pointing that out. I am trying to encourage you to provide the fix.
As I don't believe I have the option to rely on the privsep alone.
>
> > You need to provide a universal fix for all, not a partial fix for only some.
> >
>
> You bothered to read the the announcement by Theo? THERE WILL BE A FIX.
> However, we want to ensure we can get as many people to a semi-safe
> position *BEFORE* every black hat in the gawd damn net gets their hands on
> it.
>
> Ain't that a good idea? =) Or would you rather have a hacker crack your
> system before you even get a chance to patch it? Take your choice.
I realize you must be under a lot of presure to get this problem fixed,
and I intend to apply the fix as soon as it is released.
>
> - Ben
--
Douglas E. Engert <DEEn...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Steve VanDevender
> Incorrect, 3.1 has Privsep.
Funny, I can't find the options in the stock OpenSSH 3.1p1 source tree.
If it was available, it was obviously as an unsupported patch at the
time.
> Look at it this way. Do you want us to release the expliot and the patch
> now? Or would you rather have us wait the few days to gather patch fixes
> so hopefully 70% of those following along can at least be semiprotected?
I, personally, would much rather have a patch that fixes the real
security problem now for the platforms for which privilege separation is
problematic (like Tru64 UNIX with C2 security) so that my systems will
be protected whether or not I can get privilege separation working on
them. I'd like to get it working on all of them eventually, but it's
clear from the flurry of bug reports and activity this week that it's
just not ready for widespread production use yet.
> This is the correct course of action. I agree with Theo's reasons 100%.
I think it's good that Theo put out the alert and said that privilege
separation (on the platforms where it works) will prevent the exploit.
I don't think it's realistic to expect that everyone can rush privilege
separation into production as a means of addressing this problem. You
can compain that vendors should have helped you get this working
earlier, but it doesn't surprise me that most haven't responded without
a major incentive to do so.
John Hardin
> I, personally, would much rather have a patch that fixes the real
> security problem now
Ben, Theo, whoever can answer:
Is fixing the underlying security problem that much more thorny a
problem than getting privsep working on all/most/many platforms?
--
John Hardin <jo...@aproposretail.com>
Internal Systems Administrator voice: (425) 672-1304
Apropos Retail Management Systems, Inc. fax: (425) 672-0192
-----------------------------------------------------------------------
Any time that PR dominates the information stream, you can't trust
the information.
- CRYPTO-GRAM 01/2002
-----------------------------------------------------------------------
5 days until First Class postage goes up to 37 cents
Theo de Raadt
understands, please educate him. I'm sick of people who are not
thinking this through.
> Date: Tue, 25 Jun 2002 16:47:03 -0500
> From: "Douglas E. Engert" <deen...@anl.gov>
> X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
> X-Accept-Language: en
> MIME-Version: 1.0
> CC: openssh-...@mindrot.org, ope...@openbsd.org
> Subject: Upcoming OpenSSH vulnerability
> References: <20020625104024.GA29885@faui02> <2002062517...@jenny.crlsca.adelphia.net>
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> >From all of the e-mail recently, it appears that the "solution" to the
> upcomming OpenSSH vulnerability will be to run OpenSSH-3.3 with the Privilege
> Separation enabled.
>
> This scares the daylights out of me! Think about what you are doing here.
>
> (1) OpenSSH 3.3 with the privsep code has been only out for less then a week.
>
> (2) Its hundreds of lines of code.
>
> (3) The privsep does not run on all platforms
>
> (4) The privsep does not work with all the features in current ssh.
>
> (5) The privsep code has SSHD using here-to-for unused operating system features.
>
> (6) People with local modifications to SSH may not be able to
> integrate them in such a short time frame.
>
> Don't get me wrong, the privsep concept looks like a great idea, as a second
> line of defense. But it should not be the primary defense.
>
> A fix is needed for the original bug. You still need it to keep the hackers
> off the machine. Saying that they are confined to the unprivileged child process
> still lets then have access to cycles and the network where they can try and
> attack the operating system and your network from inside.
>
> The other aspect of this is the reliability of 3.3. With all the new code
> what other problems might be introduced?
>
> If you publish the problem, with out a real fix, and expect everyone to
> implement 3.3 with privsep you will have a lot of people upset who can't run 3.3 or
> can't run the privsep code. These people will be left out in the cold.
>
> You need to provide a universal fix for all, not a partial fix for only some.
>
> Thanks for listening.
>
> --
>
> Douglas E. Engert <DEEn...@anl.gov>
> Argonne National Laboratory
> 9700 South Cass Avenue
> Argonne, Illinois 60439
> (630) 252-5444
_______________________________________________
Theo de Raadt
disclosure procedure.
Immunization.
Chris Adams
> I, personally, would much rather have a patch that fixes the real
> problematic (like Tru64 UNIX with C2 security) so that my systems will
The next release will support privsep on Tru64 for pre-auth but not
post-auth.
As far as I can see, post-auth privsep just won't work for post-auth on
Tru64. setup_session_sia() needs to be called as root, and if a PTY is
to be allocated, needs to be called after the PTY is allocated and
connected to the client.
--
Chris Adams <cma...@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Phil Howard
| I think it's good that Theo put out the alert and said that privilege
| separation (on the platforms where it works) will prevent the exploit.
| I don't think it's realistic to expect that everyone can rush privilege
| separation into production as a means of addressing this problem. You
| can compain that vendors should have helped you get this working
| earlier, but it doesn't surprise me that most haven't responded without
| a major incentive to do so.
Apparently the non-portable OpenSSH has had this feature working
for a while. Given it is a security feature, it's really wrong
that vendors have failed to get it working on their platforms.
Security in and of itself should be the major incentive to do so.
Why should the authors of OpenSSH be the only ones to be expected
to address security issues in a timely manner? And even if they
do, how can they be expected to make source patches that work
universally if there are crippled versions of OpenSSH ported to
certain platforms which can make these patches not work? What
better incentive can you think of to get them to budge but a real
live security situation? If they can't respond to that, then it
is time to write them off as another MSFT-wannabe.
--
-----------------------------------------------------------------
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| phil-...@ipal.net | Texas, USA | http://phil.ipal.org/ |
-----------------------------------------------------------------
Corinna Vinschen
> On Tue, Jun 25, 2002 at 04:51:26PM -0700, Steve VanDevender wrote:
>
> | I think it's good that Theo put out the alert and said that privilege
> | separation (on the platforms where it works) will prevent the exploit.
> | I don't think it's realistic to expect that everyone can rush privilege
> | separation into production as a means of addressing this problem. You
> | can compain that vendors should have helped you get this working
> | earlier, but it doesn't surprise me that most haven't responded without
> | a major incentive to do so.
>
> Apparently the non-portable OpenSSH has had this feature working
> for a while. Given it is a security feature, it's really wrong
> that vendors have failed to get it working on their platforms.
> Security in and of itself should be the major incentive to do so.
> Why should the authors of OpenSSH be the only ones to be expected
> to address security issues in a timely manner? And even if they
> do, how can they be expected to make source patches that work
> universally if there are crippled versions of OpenSSH ported to
> certain platforms which can make these patches not work? What
> better incentive can you think of to get them to budge but a real
> live security situation? If they can't respond to that, then it
> is time to write them off as another MSFT-wannabe.
You're living in an ideal world, right?
Corinna
--
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vins...@redhat.com
Phil Howard
| On Tue, Jun 25, 2002 at 09:24:12PM -0500, Phil Howard wrote:
| > On Tue, Jun 25, 2002 at 04:51:26PM -0700, Steve VanDevender wrote:
| >
| > | I think it's good that Theo put out the alert and said that privilege
| > | separation (on the platforms where it works) will prevent the exploit.
| > | I don't think it's realistic to expect that everyone can rush privilege
| > | separation into production as a means of addressing this problem. You
| > | can compain that vendors should have helped you get this working
| > | earlier, but it doesn't surprise me that most haven't responded without
| > | a major incentive to do so.
| >
| > Apparently the non-portable OpenSSH has had this feature working
| > for a while. Given it is a security feature, it's really wrong
| > that vendors have failed to get it working on their platforms.
| > Security in and of itself should be the major incentive to do so.
| > Why should the authors of OpenSSH be the only ones to be expected
| > to address security issues in a timely manner? And even if they
| > do, how can they be expected to make source patches that work
| > universally if there are crippled versions of OpenSSH ported to
| > certain platforms which can make these patches not work? What
| > better incentive can you think of to get them to budge but a real
| > live security situation? If they can't respond to that, then it
| > is time to write them off as another MSFT-wannabe.
|
| You're living in an ideal world, right?
It depends on whose definition you want to use. Bill Gates' definition?
How long has the opportunity to port privilege separation been there?
--
-----------------------------------------------------------------
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| phil-...@ipal.net | Texas, USA | http://phil.ipal.org/ |
-----------------------------------------------------------------
Corinna Vinschen
> On Wed, Jun 26, 2002 at 09:50:27AM +0200, Corinna Vinschen wrote:
> | On Tue, Jun 25, 2002 at 09:24:12PM -0500, Phil Howard wrote:
> | > live security situation? If they can't respond to that, then it
> | > is time to write them off as another MSFT-wannabe.
> |
> | You're living in an ideal world, right?
>
> It depends on whose definition you want to use. Bill Gates' definition?
I'm working for Red Hat so it should be obvious that I don't follow
Bill Gates' definition. Especially I don't think that this is a
valid comment. We don't talk about good and bad or correct and
incorrect.
> How long has the opportunity to port privilege separation been there?
It's not privilege separation since that hasn't to be ported. It's
the OS dependend concepts used by privilege separation. Regardless
of what you or me are thinking about the different concepts of Windows
and POSIX systems, it's (not only) Cygwin's problem to get the POSIX
concepts working on a platform which is pretty different. E. g. the
concept of descriptor passing. It's known on Windows systems and it's
probably no problem to get that working on systems which are lacking
any security concept (9x/Me). It is a problem, though, to fit the
Windows concept of handle passing into the POSIX concept of descriptor
passing using sendmsg/recvmsg. The problem is that the Windows concept
requires the involved processes to have knowledges and permissions
on each other, which is something hidden in the kernel on POSIX systems.
Again, this isn't a question of good or bad, correct or incorrect, it's
just a question of being different. In this case, the differences are
so that we still don't have an implementation of descriptor passing
using sendmsg/recvmsg in Cygwin. That's unfortunate and we're working
on that (still discussing the best way to do it) but you won't change
that in a minute.
Another concept is chroot. This isn't known at all on Windows
systems. So our implementation is just a fake. But due to that
restriction in the underlying OS *we depend on* we have no other
way to accomplish a chroot.
So what? Do you just shrug and disallow Windows users the usage of
sshd since you don't like the concept of the OS? I'd find this
attitude somewhat ignorant but I still hope that you actually don't
mean it that way.
Corinna
--
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vins...@redhat.com
Corinna Vinschen
> [...]
Oh, and if that's not clear from my posting. I'm not talking
about Windows/Cygwin only. It's just the example I know the most
of. I'm also talking about systems which are lacking features
and which won't change since the manufacturer doesn't exist anymore
or for any other reason.
Phil Howard
In the interim, Windows users might be stuck with whatever level of
security exists had Privilege Separation not been created. Maybe a
direction to pursue is to not implement exactly what is done in POSIX
(since clearly if this is the case, Cygwin isn't completely POSIX),
but to implement something that isolates a process as much as can be
done within Windows. Maybe that's a daemon running somewhere to do
the tasks, instead of a child in chroot. And maybe instead of doing
descriptor passing, the process can just stay and shuffle data between
descriptors for now.
As for changing things in a minute, I don't see that as having been
the need to do. Privilege Separation has been in OpenSSH for a couple
months or so as beta. My understanding of beta is that serves not only
an opportunity to find bugs early, but for developers (those who are
porting OpenSSH to others than OpenBSD) to have a head start on the
task of porting and making decisions.
--
-----------------------------------------------------------------
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| phil-...@ipal.net | Texas, USA | http://phil.ipal.org/ |
-----------------------------------------------------------------
Phil Howard
| Oh, and if that's not clear from my posting. I'm not talking
| about Windows/Cygwin only. It's just the example I know the most
| of. I'm also talking about systems which are lacking features
| and which won't change since the manufacturer doesn't exist anymore
| or for any other reason.
And some of those machines may be security vulnerable without SSH
even being in the picture. If a feature is needed for them to be
secure and they don't have the feature, then they are not secure.
But why does everyone wait to the last minute to do this?
Ben Lindstrom
Or the company is SGI and their flagship product IRIX is really in
maintance mode because the company is not doing so hot in light of losing
contracts left and right to Linux vendors for large rendering farms.
- Ben
On Wed, 26 Jun 2002, Corinna Vinschen wrote:
> On Wed, Jun 26, 2002 at 11:44:59AM +0200, Corinna Vinschen wrote:
> > [...]
>
> Oh, and if that's not clear from my posting. I'm not talking
> about Windows/Cygwin only. It's just the example I know the most
> of. I'm also talking about systems which are lacking features
> and which won't change since the manufacturer doesn't exist anymore
> or for any other reason.
>
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Developer
> Red Hat, Inc.
> mailto:vins...@redhat.com
Chris Adams
> From: Theo de Raadt <der...@cvs.openbsd.org>
> Subject: Upcoming OpenSSH vulnerability
> To: bug...@securityfocus.com
> Cc: anno...@openbsd.org
> Cc: d...@iss.net
> Cc: mi...@openbsd.org
<snip>
> 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.
<snip>
> 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).
1) I've done most of the work getting OpenSSH working on Tru64 Unix, not
any "vendor". Compaq^WHP doesn't support OpenSSH because they've got
a license for SSH.com's software and make that version available for
free for Tru64 (I don't use it because I prefer OpenSSH). Telling
them to fix something they not only don't support but supply a
different implementation of is not real bright.
2) What happened to the interim release on Friday? I (as everyone is)
am very busy, and allocated my time according to what was said. I
did submit a patch late Tuesday, but it was not included (hence,
privsep still does not work on Tru64). There was a "test" release
for a few hours last night (sorry, I guess I'm deficient because I
need sleep). The following patch is still needed on Tru64 (not
because FD passing is broken but because audit and enhanced security
modes require root in the session setup, and if a PTY is allocated,
the session setup needs to be done after PTY allocation - I don't see
how to make that work with privsep):
diff -urN openssh-3.4p1-dist/sshd.c openssh-3.4p1/sshd.c
--- openssh-3.4p1-dist/sshd.c Tue Jun 25 18:24:19 2002
+++ openssh-3.4p1/sshd.c Wed Jun 26 10:42:00 2002
@@ -624,7 +624,7 @@
/* XXX - Remote port forwarding */
x_authctxt = authctxt;
-#ifdef BROKEN_FD_PASSING
+#if defined(BROKEN_FD_PASSING) || defined(HAVE_OSF_SIA)
if (1) {
#else
if (authctxt->pw->pw_uid == 0 || options.use_login) {
--
Chris Adams <cma...@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Kevin Steves
> How long has the opportunity to port privilege separation been there?
March. Big sync on 3/21 followed by stuff to get things somewhat
working on a few platforms on 3/22.
20020322
- (stevesk) HAVE_ACCRIGHTS_IN_MSGHDR configure support
- (stevesk) [monitor.c monitor_wrap.c] #ifdef HAVE_PW_CLASS_IN_PASSWD
- (stevesk) configure and cpp __FUNCTION__ gymnastics to handle nielsisms
- (stevesk) [monitor_fdpass.c] support for access rights style file
descriptor passing
- (stevesk) [auth2.c] merge cleanup/sync
- (stevesk) [defines.h] hp-ux 11 has ancillary data style fd passing, but
is missing CMSG_LEN() and CMSG_SPACE() macros.
- (stevesk) [defines.h] #define MAP_ANON MAP_ANONYMOUS for HP-UX; other
platforms may need this--I'm not sure. mmap() issues will need to be
addressed further.
- (tim) [cipher.c] fix problem with OpenBSD sync
- (stevesk) [LICENCE] OpenBSD sync
20020321
- (bal) OpenBSD CVS Sync
Ben Lindstrom
> > 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).
>
> 1) I've done most of the work getting OpenSSH working on Tru64 Unix, not
> any "vendor". Compaq^WHP doesn't support OpenSSH because they've got
> a license for SSH.com's software and make that version available for
> free for Tru64 (I don't use it because I prefer OpenSSH). Telling
> them to fix something they not only don't support but supply a
> different implementation of is not real bright.
>
HP/Compaq uses OpenSSH in their routers and switches.
> 2) What happened to the interim release on Friday? I (as everyone is)
> am very busy, and allocated my time according to what was said. I
> did submit a patch late Tuesday, but it was not included (hence,
> privsep still does not work on Tru64). There was a "test" release
> for a few hours last night (sorry, I guess I'm deficient because I
> need sleep). The following patch is still needed on Tru64 (not
> because FD passing is broken but because audit and enhanced security
> modes require root in the session setup, and if a PTY is allocated,
> the session setup needs to be done after PTY allocation - I don't see
> how to make that work with privsep):
>
Say thank you to who ever leaked the expliot.
Next track them down and cut their hands off.
> diff -urN openssh-3.4p1-dist/sshd.c openssh-3.4p1/sshd.c
> --- openssh-3.4p1-dist/sshd.c Tue Jun 25 18:24:19 2002
> +++ openssh-3.4p1/sshd.c Wed Jun 26 10:42:00 2002
> @@ -624,7 +624,7 @@
> /* XXX - Remote port forwarding */
> x_authctxt = authctxt;
>
> -#ifdef BROKEN_FD_PASSING
> +#if defined(BROKEN_FD_PASSING) || defined(HAVE_OSF_SIA)
> if (1) {
No. Fix Configure.ac. There is a reason Tim and I agreed on
that define. So we don't have to litter the source with more #ifdef
changes.
Better yet now we are post 3.4 we need a real solution.
Security releases never go the way you want them to. I've seen more
fubared released because of expliot leaks in the last 10 years than
anything else. And it is just as frustrating for us as you.
- Ben
Chris Adams
> > 1) I've done most of the work getting OpenSSH working on Tru64 Unix, not
> > any "vendor". Compaq^WHP doesn't support OpenSSH because they've got
> > a license for SSH.com's software and make that version available for
> > free for Tru64 (I don't use it because I prefer OpenSSH). Telling
> > them to fix something they not only don't support but supply a
> > different implementation of is not real bright.
>
> HP/Compaq uses OpenSSH in their routers and switches.
I really don't think they use Tru64 Unix in their routers and switches,
nor are any of the same people involved.
> > 2) What happened to the interim release on Friday? I (as everyone is)
> > am very busy, and allocated my time according to what was said. I
> > did submit a patch late Tuesday, but it was not included (hence,
> > privsep still does not work on Tru64). There was a "test" release
> > for a few hours last night (sorry, I guess I'm deficient because I
> > need sleep). The following patch is still needed on Tru64 (not
> > because FD passing is broken but because audit and enhanced security
> > modes require root in the session setup, and if a PTY is allocated,
> > the session setup needs to be done after PTY allocation - I don't see
> > how to make that work with privsep):
>
> Say thank you to who ever leaked the expliot.
Sorry, I wasn't aware of that. It would have been nice if that had been
at least mentioned in the release notes or something, since it was a
significant change from the previously announced schedule.
> Next track them down and cut their hands off.
That I would love to do.
> > diff -urN openssh-3.4p1-dist/sshd.c openssh-3.4p1/sshd.c
> > --- openssh-3.4p1-dist/sshd.c Tue Jun 25 18:24:19 2002
> > +++ openssh-3.4p1/sshd.c Wed Jun 26 10:42:00 2002
> > @@ -624,7 +624,7 @@
> > /* XXX - Remote port forwarding */
> > x_authctxt = authctxt;
> >
> > -#ifdef BROKEN_FD_PASSING
> > +#if defined(BROKEN_FD_PASSING) || defined(HAVE_OSF_SIA)
> > if (1) {
>
> No. Fix Configure.ac. There is a reason Tim and I agreed on
> that define. So we don't have to litter the source with more #ifdef
> changes.
Then name the define something else, like "NO_POSTAUTH_PRIVSEP", and
auto-define it if BROKEN_FD_PASSING is defined. FD passing is not
broken on Tru64 (4.x or 5.x as far as I can tell). If something else is
added in the future that uses FD passing, it should be supported on
Tru64, so Tru64 should not set BROKEN_FD_PASSING in configure.ac.
> Better yet now we are post 3.4 we need a real solution.
As I said above, I don't see how to do post-auth privsep on Tru64. The
requirements just don't seem to match the capabilities. The only thing
I can see to do is to open a PTY unconditionally before post-auth
privsep and close it later if it is not needed (but I don't know for
sure that would work either). That would be a fairly major change;
would such a change be accepted back into "core" OpenSSH?
--
Chris Adams <cma...@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Ben Lindstrom
> > > diff -urN openssh-3.4p1-dist/sshd.c openssh-3.4p1/sshd.c
> > > --- openssh-3.4p1-dist/sshd.c Tue Jun 25 18:24:19 2002
> > > +++ openssh-3.4p1/sshd.c Wed Jun 26 10:42:00 2002
> > > @@ -624,7 +624,7 @@
> > > /* XXX - Remote port forwarding */
> > > x_authctxt = authctxt;
> > >
> > > -#ifdef BROKEN_FD_PASSING
> > > +#if defined(BROKEN_FD_PASSING) || defined(HAVE_OSF_SIA)
> > > if (1) {
> >
> > No. Fix Configure.ac. There is a reason Tim and I agreed on
> > that define. So we don't have to litter the source with more #ifdef
> > changes.
>
> Then name the define something else, like "NO_POSTAUTH_PRIVSEP", and
> auto-define it if BROKEN_FD_PASSING is defined. FD passing is not
> broken on Tru64 (4.x or 5.x as far as I can tell). If something else is
> added in the future that uses FD passing, it should be supported on
> Tru64, so Tru64 should not set BROKEN_FD_PASSING in configure.ac.
>
It will be left at BROKEN_FD_PASSING because when all platforms are
sqaured away that will be what is set if we run accross such a platform.
No one said what was going in 3.4 was set in stone for changes.=)
> > Better yet now we are post 3.4 we need a real solution.
>
> As I said above, I don't see how to do post-auth privsep on Tru64. The
> requirements just don't seem to match the capabilities. The only thing
> I can see to do is to open a PTY unconditionally before post-auth
> privsep and close it later if it is not needed (but I don't know for
> sure that would work either). That would be a fairly major change;
> would such a change be accepted back into "core" OpenSSH?
>
If you can get a preview fix posted. I'll work within the OpenSSH porable
group to ensure that some version of it gets included.
If that preview fix says 'we always open a temporary TTY' then so be it.
We can look at how to handle non-tty case handled after.
- Ben
Damien Miller
> > How long has the opportunity to port privilege separation been there?
>
> It's not privilege separation since that hasn't to be ported. It's
> the OS dependend concepts used by privilege separation.
I have been telling people that privsep will be switched on by default
in the next release since it showed up in the builds.
Look what happened:
- Did anyone test it? A couple of people (no vendors)
- Did anyone comment on my patches to get it working more completely?
None, just complaints
That's why we're annoyed.
-d
(Not singling out Corinna here, just the attitude)
Damien Miller
> If you can get a preview fix posted. I'll work within the OpenSSH porable
> group to ensure that some version of it gets included.
I am happy to do a 3.4p2 release in a couple of days to get platform
issues resolved if there is sufficient demand.
-d
Chris Adams
> >
> > As I said above, I don't see how to do post-auth privsep on Tru64. The
> > requirements just don't seem to match the capabilities. The only thing
> > I can see to do is to open a PTY unconditionally before post-auth
> > privsep and close it later if it is not needed (but I don't know for
> > sure that would work either). That would be a fairly major change;
> > would such a change be accepted back into "core" OpenSSH?
> >
>
> group to ensure that some version of it gets included.
>
> We can look at how to handle non-tty case handled after.
I guess from that I should go ahead and make OpenSSH always open the TTY
and then discard it if it is not needed for all platforms, not just
Tru64 (at least the AIX folks were looking for this as well). That
would lessen the "#ifdef HAVE_OSF_SIA" count.
Unless I head otherwise, I'll work towards that.
--
Chris Adams <cma...@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Chris Adams
> I guess from that I should go ahead and make OpenSSH always open the TTY
> and then discard it if it is not needed for all platforms, not just
> Tru64 (at least the AIX folks were looking for this as well). That
> would lessen the "#ifdef HAVE_OSF_SIA" count.
Thinking about this some more (I never think before I send apparently
:-) )...
If a TTY were always allocated before post-auth privsep kicked in, the
whole BROKEN_FD_PASSING would go away (because as far as I can see in a
quick look, FD passing is only used for the parent to open a TTY for the
child). This could just always be done and the FD passing code and
privsep wrapping of pty_allocate() would go away.
Or, the TTY pre-allocation could depend on BROKEN_FD_PASSING,
HAVE_OSF_SIA, and _AIX.