Re: [d-security] Re: DSA-134-1

[Phillip Hofmeister]

On Thu, Jun 27, 2002 at 09:12:41AM +0100, Tim Haynes wrote:
> I'm trying not to think how many Debian policies have been bent because of
> "oh no! it's ssh!"-factor - porting a protocol-2-enabled *new feature* down
> to Stable with the resultant paragraphs on `create a proto-2 keypair' and
> `these are untested' in the DSA causes inconvenience to folks running
> Stable+Secure boxes, in addition to those of us using Testing but keeping
> an eye on DSAs.
> And we're all going to have to upgrade again when 3.4 comes out properly as
> it is...
>
Might I suggest you consider dpkg --force-downgrade 

If not you will be running around next week when our good friend Theo finds a 
vulnerability
in 3.4...just a thought


Phil 


pgpO3KyAGtmJz.pgp
Description: PGP signature

Re: [d-security] Re: DSA-134-1

[Tim Haynes]

Wichert Akkerman <[EMAIL PROTECTED]> writes:

> Previously Christian Hammers wrote:
>
> > Don't be too hard to him, if he'd pointed out that only default BSD is
> > vulnerable it would not have been too hard to find the exploit before
> > everybody had updated.
> 
> He could have mentioned ssh protocol 1 wasn't vulnerable..

At the very least.

I'm trying not to think how many Debian policies have been bent because of
"oh no! it's ssh!"-factor - porting a protocol-2-enabled *new feature* down
to Stable with the resultant paragraphs on `create a proto-2 keypair' and
`these are untested' in the DSA causes inconvenience to folks running
Stable+Secure boxes, in addition to those of us using Testing but keeping
an eye on DSAs.
And we're all going to have to upgrade again when 3.4 comes out properly as
it is...

Could I suggest that `until we're told what it is, there is no problem' be
considered as an approach? ;/

~Tim
-- 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [d-security] Re: DSA-134-1

[Wichert Akkerman]

Previously Christian Hammers wrote:
> Don't be too hard to him, if he'd pointed out that only default BSD is 
> vulnerable it would not have been too hard to find the exploit before 
> everybody had updated. 

He could have mentioned ssh protocol 1 wasn't vulnerable..

Wichert.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[InfoEmergencias - Luis Gómez]

El mar, 25-06-2002 a las 12:40, Robert van der Meulen escribió:
> and disclosure is only done when it doesn't affect
> openbsd (or the '5 years without..' line on openbsd.org).

You'll love this one:

"One remote hole in the default install, in nearly 6 years!"

Great X'DD
Depending on the language you see their web on, it may or may not have
already changed...

Luis
 
-- 
Luis Gómez Miralles
InfoEmergencias - Technical Department
Phone (+34) 654 24 01 34
Fax (+34) 963 49 31 80
[EMAIL PROTECTED]

PGP Public Key available at http://www.infoemergencias.com/lgomez.asc


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [d-security] Re: DSA-134-1

[Christian Hammers]

On Wed, Jun 26, 2002 at 07:23:49PM +0200, Florian Weimer wrote:
> Well, it appears if OpenSSH 1.2.3 was *not* vulnerable, so the whole
> exercise was rather pointless.
But drill inspector Theo ("update and don't ask questions, soldier!"), showed 
at least how good our new security upload architecture and how fast the 
security team is *g* 
 
> Thanks, Theo.
Don't be too hard to him, if he'd pointed out that only default BSD is 
vulnerable it would not have been too hard to find the exploit before 
everybody had updated. 

bye,

-christian-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[Michael Furr]

On Wed, 2002-06-26 at 13:23, Florian Weimer wrote:
> Well, it appears if OpenSSH 1.2.3 was *not* vulnerable, so the whole
> exercise was rather pointless.
> 
> Thanks, Theo.

"Worst advisory ever."

-m


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[Florian Weimer]

Florian Weimer <[EMAIL PROTECTED]> writes:

> Wichert Akkerman <[EMAIL PROTECTED]> writes:
>
>> Definitely. I really wish we could do more but the complete lack
>> of more information we have make things difficult. Backporting
>> OpenSSH 3.3p1 to to potato is also slightly complicated by missing
>> build dependencies, but we hope to have packages ready sometime
>> tomorrow.
>
> Is this worth the effort if there's still a remote nobody exploit?
> At least that's the way understand the DSA.

Well, it appears if OpenSSH 1.2.3 was *not* vulnerable, so the whole
exercise was rather pointless.

Thanks, Theo.

-- 
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart   http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT  fax +49-711-685-5898


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[Oystein Viggen]

* [Moritz Schulte] 

> As a side note: many network daemons could make use of this special
> feature to be more secure.

Off the top of my head, I can think of telnetd, popd and imapd.

For ssh, you would need to support public key authentication in the
passwd server, and ftp will have to deal with the old "have to open port
20 on the fly" problem.

So privsep will still be useful on the Hurd, with the only improvement
being that you don't really need the sshd user.

Oystein
-- 
When in doubt: Recompile.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[Moritz Schulte]

Phillip Hofmeister <[EMAIL PROTECTED]> writes:

[Not directly in reference to this problem, just some more
information.]

> *TECHNICALLY* every login is root.

Yes, that is how it works in Unix.  People could say that this concept
is not perfect.  Since Debian is not only a GNU/Linux distribution
anymore...

In GNU (that is, GNU/Hurd) things are different: a login happens
without _any_ UID - a concept Unix does not know about.  Your login
program contacts the Hurd "password server", which runs as root and
does nothing beside verifying authentications and giving out
"authentication handles" to processes, which contain Unix UIDs/GIDs.

That is simply the natural way of doing things when you are not only
limited to lower privileges like it is the case in Unix and are able
to raise your privileges.

As a side note: many network daemons could make use of this special
feature to be more secure.

moritz
-- 
[EMAIL PROTECTED] - http://duesseldorf.ccc.de/~moritz/
GPG fingerprint = 3A14 3923 15BE FD57 FC06  B501 0841 2D7B 6F98 4199


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[Christian Jaeger]

At 1:01 Uhr +0200 26.06.2002, Christian Jaeger wrote:
(Well, it would be easy if logins are username/password only: if the 
check for correct username/password is done by process 1, process 2 
has to provide them which it can't if the cracker doesn't know them 
anyway. But since ssh also allows public-key based logins, and I 
would guess that the key check is done by process 2, it looks 
different. Sorry if this starts to be OT.)


Replying to myself: even in the case of public-key authentification 
the work is done in process 1. (Well of course it has to be done 
there since only process 1 does have access to the public keys :o)
There's a link to http://www.citi.umich.edu/u/provos/ssh/privsep.html 
on www.openssh.org now, which also explains it a bit.
(BTW I've noticed that the child process is really just a forked copy 
of the parent, so both processes do have the same code. (Which is not 
any risk in itself of course.))


Christian.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[Greg Hunt]

Well I'm not an open-bsd developer nor have I looked through the privilege 
seperation code so I only know what I read at 
http://www.citi.umich.edu/u/provos/ssh/privsep.html but according to that site 
(linked to from openssh.com) the privileged process (process 1) forks the 
unprivileged child (process 2) when a connection is made, this child talks to 
the client and requests authentication from the parent. If the authentication 
is sucessfull the parent passes the child a PTY, if not there's not much the 
child process can do. 
The child itself is never able to say "give me a root shell",  or "give me a 
shell for user xyz" so the child becoming corrupted doesn't compromise the 
security of the whole system (that's the point of priv seperation).
-Greg

PS: the site linked to above does a much better job of explaining this

> >this shellcode is executed as user ralf, not as user root.
> 
> I'm not worried about a shell spawned by the chrooted process.
> 
> Chroot and su to some undangerous user helps if that's one-way only, 
> i.e. the process doesn't have any connection to sensitive areas 
> anymore. But in the case of sshd, it's not one-way: as far as I 
> understand, the process running in the chroot as 'sshd' (say process 
> 2) user does the communication with the client, but, and that's the 
> problem, it does have a connection with a sister process running as 
> root (say process 1) which it tells to launch a login shell for the 
> user requested by the client. Normally, process 2 would of course 
> only advise process 1 to do that if the remote client correctly 
> identifies itself/gives the password. But if a malicious client 
> submits data that corrupts process 2, he could make it to tell 
> process 1 to launch a login shell for root. How should process 1 find 
> out whether process 2 has been corrupted?
> 
> (Well, it would be easy if logins are username/password only: if the 
> check for correct username/password is done by process 1, process 2 
> has to provide them which it can't if the cracker doesn't know them 
> anyway. But since ssh also allows public-key based logins, and I 
> would guess that the key check is done by process 2, it looks 
> different. Sorry if this starts to be OT.)
> 
> Christian.
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
--SupplyEdge---
Greg Hunt
800-733-3380 x 107
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[Christian Jaeger]

At 17:16 Uhr +0200 25.06.2002, Ralf Dreibrodt wrote:

this shellcode is executed as user ralf, not as user root.


I'm not worried about a shell spawned by the chrooted process.

Chroot and su to some undangerous user helps if that's one-way only, 
i.e. the process doesn't have any connection to sensitive areas 
anymore. But in the case of sshd, it's not one-way: as far as I 
understand, the process running in the chroot as 'sshd' (say process 
2) user does the communication with the client, but, and that's the 
problem, it does have a connection with a sister process running as 
root (say process 1) which it tells to launch a login shell for the 
user requested by the client. Normally, process 2 would of course 
only advise process 1 to do that if the remote client correctly 
identifies itself/gives the password. But if a malicious client 
submits data that corrupts process 2, he could make it to tell 
process 1 to launch a login shell for root. How should process 1 find 
out whether process 2 has been corrupted?


(Well, it would be easy if logins are username/password only: if the 
check for correct username/password is done by process 1, process 2 
has to provide them which it can't if the cracker doesn't know them 
anyway. But since ssh also allows public-key based logins, and I 
would guess that the key check is done by process 2, it looks 
different. Sorry if this starts to be OT.)


Christian.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[Greg Hunt]

Yes it's still not a good thing for sometime to have a shell with no priv's but 
someone asked "better how?", I'm pretty sure if most admins had a choice 
between an attacker having root access or an attacker having a chrooted shell 
with no privs they would choose the latter. Seeing as how there isn't a patch 
yet for the bug, it's this or nothing. 
-Greg

> >Theo de Raadt said in a post to Bugtraq the exploit won't work on sshd with 
> >privilege seperation enabled, however even if it did work it'd be better to 
> >have an attacker get a chrooted shell with no privs instead of root access 
> >to the entire system. 
> >
> In which case you just need a local exploit to go with your remote exploit.
> 
> makes it harder but not impossible.
> 

-- 
--SupplyEdge---
Greg Hunt
800-733-3380 x 107
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[Florian Weimer]

"Noah L. Meyerhans" <[EMAIL PROTECTED]> writes:

> A local exploit that can be run by a non-root user in an empty chroot.
> Those are considerably harder to come by than the standard local
> exploit.  Are any known to exist at all?

Have you examined all those signedness bugs in the kernel which have
been fixed based on results from the checker project? :-/

-- 
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart   http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT  fax +49-711-685-5898


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[Noah L. Meyerhans]

On Tue, Jun 25, 2002 at 06:01:36PM -0400, Noah L. Meyerhans wrote:
> A local exploit that can be run by a non-root user in an empty chroot.

Oh, and I forgot to mention that non-root user does not have write
permissions on the chroot.

There's really not much you can do with such an environment.

noah

-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 


pgpKtOq0vKt81.pgp
Description: PGP signature

Re: DSA-134-1

[Noah L. Meyerhans]

On Tue, Jun 25, 2002 at 11:58:13PM +0200, James Nord wrote:
> >
> In which case you just need a local exploit to go with your remote exploit.

A local exploit that can be run by a non-root user in an empty chroot.
Those are considerably harder to come by than the standard local
exploit.  Are any known to exist at all?

noah

-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 


pgpdQ2zhSlIxZ.pgp
Description: PGP signature

Re: DSA-134-1

[Florian Weimer]

James Nord <[EMAIL PROTECTED]> writes:

>> Theo de Raadt said in a post to Bugtraq the exploit won't work on
>> sshd with privilege seperation enabled, however even if it did work
>> it'd be better to have an attacker get a chrooted shell with no
>> privs instead of root access to the entire system.

> In which case you just need a local exploit to go with your remote exploit.

Or you don't care about the local system ressources at all and just
abuse the network (like some Code Red variant did).

-- 
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart   http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT  fax +49-711-685-5898


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[James Nord]

i unterstand it as remote chrooted nobody exploit, this is much more
better than a remote root-exploit.
 


better in what way?
   

Theo de Raadt said in a post to Bugtraq the exploit won't work on sshd with privilege seperation enabled, however even if it did work it'd be better to have an attacker get a chrooted shell with no privs instead of root access to the entire system. 


In which case you just need a local exploit to go with your remote exploit.

makes it harder but not impossible.

/James


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[Greg Hunt]

Theo de Raadt said in a post to Bugtraq the exploit won't work on sshd with 
privilege seperation enabled, however even if it did work it'd be better to 
have an attacker get a chrooted shell with no privs instead of root access to 
the entire system. 
> > i unterstand it as remote chrooted nobody exploit, this is much more
> > better than a remote root-exploit.
> 
> better in what way?



-- 
--SupplyEdge---
Greg Hunt
800-733-3380 x 107
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[martin f krafft]

also sprach Ralf Dreibrodt <[EMAIL PROTECTED]> [2002.06.25.1510 +0200]:
> i unterstand it as remote chrooted nobody exploit, this is much more
> better than a remote root-exploit.

better in what way?

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
  
"there are two major products that come out of berkeley: lsd and unix.
 we don't believe this to be a coincidence."
 -- jeremy s. anderson


pgpMIoII7mHBE.pgp
Description: PGP signature

Re: DSA-134-1

[Ralf Dreibrodt]

Hi,

Mark Janssen wrote:
> 
> On Tue, 2002-06-25 at 18:11, Phillip Hofmeister wrote:
> > *TECHNICALLY* every login is root.  Getty runs as root and then gives up 
> > root
> > to the authenticated user once PAM gives the okay...Does this mean the user
> > can break back into root?  If the exit their shell (Ctrl + D, or pick your 
> > choice
> > of logout method...) then Getty immediately respawns
> 
> No... getty exec's a shell (or a login actually) and when this exits
> the inetd restarts the getty. :)

inetd?
you mean init ;)

btw the respawn is only done, if you have the word "respawn" in
/etc/inittab before ":/sbin/getty".

but getty has not to run with _all_ root-privileges, it just has to run
as user root with some root-privileges.
for more info about this, have a look at http://www.lids.org

bye
Ralf


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[Mark Janssen]

On Tue, 2002-06-25 at 18:11, Phillip Hofmeister wrote:
> *TECHNICALLY* every login is root.  Getty runs as root and then gives up root
> to the authenticated user once PAM gives the okay...Does this mean the user
> can break back into root?  If the exit their shell (Ctrl + D, or pick your 
> choice
> of logout method...) then Getty immediately respawns

No... getty exec's a shell (or a login actually) and when this exits
the inetd restarts the getty. :)

-- 
Mark Janssen -- maniac(at)maniac.nl -- GnuPG Key Id: 357D2178
Unix / Linux, Open-Source and Internet Consultant @ SyConOS IT
Maniac.nl Unix-God.Net|Org MarkJanssen.org|nl SyConOS.com|nl


signature.asc
Description: This is a digitally signed message part

Re: DSA-134-1

[Phillip Hofmeister]

On Tue, Jun 25, 2002 at 05:16:51PM +0200, Ralf Dreibrodt wrote:
> just imagine:
> i login as root.
> su to ralf (man su)
> ralf executes any buggy programm, where someone else can insert
> shellcode.
> (e.g. chmod 777 /home/ralf -R; /home/ralf/myshellscript.sh)
> 
> this shellcode is executed as user ralf, not as user root.
> 
> there is no chance to execute the shellcode, which inserted any other
> user in /home/ralf/myshellscript.sh) as root, although i logged in as
> root. (if we assume that there is no bug in "su")

*TECHNICALLY* every login is root.  Getty runs as root and then gives up root
to the authenticated user once PAM gives the okay...Does this mean the user
can break back into root?  If the exit their shell (Ctrl + D, or pick your 
choice
of logout method...) then Getty immediately respawns


Phil


pgpqDLN836eAh.pgp
Description: PGP signature

Re: DSA-134-1

[Ralf Dreibrodt]

Hi,

Christian Jaeger wrote:
> 
> Hmm, I'm wondering if it's any better: if the attacker manages code
> to run in the chrooted daemon, I suspect he can also advise the part
> running as root to open up a new root connection? Isn't it that the
> separation simply protects against direct shell launch attacks? Well
> I'm not educated enough to know, just wondering.

just imagine:
i login as root.
su to ralf (man su)
ralf executes any buggy programm, where someone else can insert
shellcode.
(e.g. chmod 777 /home/ralf -R; /home/ralf/myshellscript.sh)

this shellcode is executed as user ralf, not as user root.

there is no chance to execute the shellcode, which inserted any other
user in /home/ralf/myshellscript.sh) as root, although i logged in as
root. (if we assume that there is no bug in "su")

bye
Ralf


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[Christian Jaeger]

At 15:10 Uhr +0200 25.06.2002, Ralf Dreibrodt wrote:

i unterstand it as remote chrooted nobody exploit, this is much more
better than a remote root-exploit.


Hmm, I'm wondering if it's any better: if the attacker manages code 
to run in the chrooted daemon, I suspect he can also advise the part 
running as root to open up a new root connection? Isn't it that the 
separation simply protects against direct shell launch attacks? Well 
I'm not educated enough to know, just wondering.


Christian.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[Tim Nicholas]

Hi,
One would have to point out that though they haven't released
anything specific yet, they say that they will, and there are real
reasons for not telling the world without providing sufficient
warning to get systems at least partially protected. Sure that might
be in some ways inconsistent with their stated policy but if they do
release all the information next week (as I think they have said
they will) then (probably) they have gone about it in as good a way
as they could really be expected to. 
As I understand it, the normal way for vendors to do this would have
been to wait until next week before saying anything at all. Probably
that would have been a clearer course of action as we wouldn't know
about it until a fix was available. No nervous week of waiting, but
also an extra week with a 'known' and presumably very serious
security whole in all our systems. 
I don't like either of those options, but I'm inclined to think that
being given an opportunity to do preemptive damage control is a Good
Thing. 


On the other hand I agree with you entirely about Theo. He is my only
problem with the OpenBSD project.

Tim

On Tue, Jun 25, 2002 at 12:40:44PM +0200, Robert van der Meulen wrote:
> 
> Quoting Paul Haesler ([EMAIL PROTECTED]):
> > Doesn't OpenBSD have a full-disclosure policy anyway?
> 
> It has 'listen to theo or fuck off' disclosure policy, which basically means
> you have to do what theo says, and no matter what you do, you'll end up with
> problems and bitching, and disclosure is only done when it doesn't affect
> openbsd (or the '5 years without..' line on openbsd.org).
> 
> Greets,
>   Robert
> 

-- 
Tim Nicholas  ||  Cilix
Email: [EMAIL PROTECTED]||   Dunedin, New Zealand
http://tim.nicholas.net.nz/   ||  Cell/SMS: +64 21 113 0399


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[Ralf Dreibrodt]

Hi,

Florian Weimer wrote:
> 
> Is this worth the effort if there's still a remote nobody exploit?
> At least that's the way understand the DSA.

i unterstand it as remote chrooted nobody exploit, this is much more
better than a remote root-exploit.

bye,

Ralf


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[Florian Weimer]

Wichert Akkerman <[EMAIL PROTECTED]> writes:

> Definitely. I really wish we could do more but the complete lack
> of more information we have make things difficult. Backporting
> OpenSSH 3.3p1 to to potato is also slightly complicated by missing
> build dependencies, but we hope to have packages ready sometime
> tomorrow.

Is this worth the effort if there's still a remote nobody exploit?
At least that's the way understand the DSA.

-- 
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart   http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT  fax +49-711-685-5898


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[Robert van der Meulen]

Quoting Paul Haesler ([EMAIL PROTECTED]):
> Doesn't OpenBSD have a full-disclosure policy anyway?

It has 'listen to theo or fuck off' disclosure policy, which basically means
you have to do what theo says, and no matter what you do, you'll end up with
problems and bitching, and disclosure is only done when it doesn't affect
openbsd (or the '5 years without..' line on openbsd.org).

Greets,
Robert
-- 
( o>  Linux Generation  

Re: DSA-134-1

[Paul Haesler]

> Previously Anthony DeRobertis wrote:
> > $VENDOR says it's broken
> > $VENDOR won't provide details
> > $VENDOR says upgrade two minor releases
> > $VENDOR says upgrading doesn't actually fix the problem
> > $VENDOR says upgrading will break things
> > Woody security update comes out before potato one.
> 
> Lovely situation, isn't it?

Doesn't OpenBSD have a full-disclosure policy anyway?

--
Paul Haesler[EMAIL PROTECTED]
ICQ: 124547085

Neutrons are wormholes. And if Blanca's dead 
clone was right, the Transmuters had all the 
degrees of freedom they could need to make 
Swift's neutrons unique.

- Yatima, in Greg Egan's "Diaspora".


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [SECURITY] [DSA-134-1] OpenSSH remote vulnerability

[Ralf Dreibrodt]

Hi,

Phillip Hofmeister wrote:
> 
> Sowhat does this mean for us running potato on internet servers?
> 
> Does this effect the daemon or the client?

this is the information markus friedl send to bugtraq and it is perhaps
the same, the debian-team got?!?

> Date: Mon, 24 Jun 2002 15:00:10 -0600
> From: Theo de Raadt <[EMAIL PROTECTED]>
> Subject: Upcoming OpenSSH vulnerability
> To: bugtraq@securityfocus.com
> Cc: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Cc: misc@openbsd.org
> 
> There is an upcoming OpenSSH vulnerability that we're working on with
> ISS.  Details will be published early next week.
> 
> However, I can say that when OpenSSH's sshd(8) is running with priv
> seperation, the bug cannot be exploited.
> 
> OpenSSH 3.3p was released a few days ago, with various improvements
> but in particular, it significantly improves the Linux and Solaris
> support for priv sep.  However, it is not yet perfect.  Compression is
> disabled on some systems, and the many varieties of PAM are causing
> major headaches.
> 
> However, everyone should update to OpenSSH 3.3 immediately, and enable
> priv seperation in their ssh daemons, by setting this in your
> /etc/ssh/sshd_config file:
> 
>   UsePrivilegeSeparation yes
> 
> Depending on what your system is, privsep may break some ssh
> functionality.  However, with privsep turned on, you are immune from
> at least one remote hole.  Understand?
> 
> 3.3 does not contain a fix for this upcoming bug.
> 
> If priv seperation does not work on your operating system, you need to
> work with your vendor so that we get patches to make it work on your
> system.  Our developers are swamped enough without trying to support
> the myriad of PAM and other issues which exist in various systems.
> You must call on your vendors to help us.
> 
> Basically, OpenSSH sshd(8) is something like 27000 lines of code.  A
> lot of that runs as root.  But when UsePrivilegeSeparation is enabled,
> the daemon splits into two parts.  A part containing about 2500 lines
> of code remains as root, and the rest of the code is shoved into a
> chroot-jail without any privs.  This makes the daemon less vulnerable
> to attack.
> 
> We've been trying to warn vendors about 3.3 and the need for privsep,
> but they really have not heeded our call for assistance.  They have
> basically ignored us.  Some, like Alan Cox, even went further stating
> that privsep was not being worked on because "Nobody provided any info
> which proves the problem, and many people dont trust you theo" and
> suggested I "might be feeding everyone a trojan" (I think I'll publish
> that letter -- it is just so funny).  HP's representative was
> downright rude, but that is OK because Compaq is retiring him.  Except
> for Solar Designer, I think none of them has helped the OpenSSH
> portable developers make privsep work better on their systems.
> Apparently Solar Designer is the only person who understands the need
> for this stuff.
> 
> 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.
> 
> Let me repeat: even if the bug exists in a privsep'd sshd, it is not
> exploitable.  Clearly we cannot yet publish what the bug is, or
> provide anyone with the real patch, but we can try to get maximum
> deployement of privsep, and therefore make it hurt less when the
> problem is published.
> 
> So please push your vendor to get us maximally working privsep patches
> as soon as possible!
> 
> 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).
> 
> Customers can judge their vendors by how they respond to this issue.
> 
> OpenBSD and NetBSD users should also update to OpenSSH 3.3 right away.
> On OpenBSD privsep works flawlessly, and I have reports that is also
> true on NetBSD.  All other systems appear to have minor or major
> weaknesses when this code is running.
> 
> (securityfocus postmaster; please post this through immediately, since
> i have bcc'd over 30 other places..)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: [SECURITY] [DSA-134-1] OpenSSH remote vulnerability

[Jones, Steven]

I would suggest it means either write a tight firewall ruleset to restrict
access or dont allow connections from the interneta t all.

Ive now donethe latter, after the previous weakness its just to great a
risk.

regards

Steven

-Original Message-
From: Phillip Hofmeister [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 25 June 2002 11:14 
To: debian-security@lists.debian.org
Subject: Re: [SECURITY] [DSA-134-1] OpenSSH remote vulnerability


Sowhat does this mean for us running potato on internet servers?

Does this effect the daemon or the client?

If it effects the daemon, is the potato version vulnerable?


Phil

On Mon, Jun 24, 2002 at 11:56:04PM +0200, Wichert Akkerman wrote:
> 
> Debian Security Advisory DSA-134-1   [EMAIL PROTECTED]
> http://www.debian.org/security/ Wichert Akkerman
> June 24, 2002
> 
> 
> 
> Package: ssh
> Problem type   : remote exploit
> Debian-specific: no
> 
> Theo de Raadt announced that the OpenBSD team is working with ISS
> on a remote exploit for OpenSSH (a free implementation of the
> Secure SHell protocol). They are refusing to provide any details on
> the vulnerability but instead are advising everyone to upgrade to
> the latest release, version 3.3.
> 
> This version was released 3 days ago and introduced a new feature
> to reduce the effect of exploits in the network handling code
> called privilege separation.  Unfortunately this release has a few
> known problems: compression does not work on all operating systems
> since the code relies on specific mmap features, and the PAM
> support has not been completed. There may be other problems as
> well.
> 
> The new privilege separation support from Niels Provos changes ssh
> to use a separate non-privileged process to handle most of the
> work. This means any vulnerability in this part of OpenSSH can
> never lead to a root compromise but only to access to a separate
> account restricted to a chroot.
> 
> Theo made it very clear this new version does not fix the
> vulnerability, instead by using the new privilege separation code
> it merely reduces the risk since the attacker can only gain access
> to a special account restricted in a chroot.
> 
> Since details of the problem have not been released we were forced
> to move to the latest release of OpenSSH portable, version 3.3p1.
> 
> Due to the short time frame we have had we have not been able to
> update the ssh package for Debian GNU/Linux 2.2 / potato yet.
> Packages for the upcoming 3.0 release (woody) are available for
> most architectures.
> 
> Please note that we have not had the time to do proper QA on these
> packages; they might contain bugs or break things unexpectedly. If
> you notice any such problems please file a bug-report so we can
> investigate.
> 
> This package introduce a new account called `sshd' that is used in
> the privilege separation code. If no sshd account exists the
> package will try to create one. If the account already exists it
> will be re-used. If you do not want this to happen you will have
> to fix this manually. 
> 
> 
> wget url
> will fetch the file for you
> dpkg -i file.deb
> will install the referenced file.
> 
> 
> Debian GNU/Linux 2.2 alias potato
> -
> 
>   Potato was released for alpha, arm, i386, m68k, powerpc and sparc.
> 
>   Package for potato are not available at the moment
> 
> 
> Debian GNU/Linux 3.0 alias woody
> -
> 
>   Woody will be released for alpha, arm, hppa, i386, ia64, m68k, mips,
>   mipsel, powerpc, s390 and sparc. Packages for m68k are not yet
>   available at this moment.
> 
> 
>   Source archives:
> 
>
http://security.debian.org/pool/updates/main/o/openssh/openssh_3.3p1-0.0wood
y1.dsc
>   Size/MD5 checksum:  751 2409524dc15e3de36ebfaa702c0311ea
>
http://security.debian.org/pool/updates/main/o/openssh/openssh_3.3p1.orig.ta
r.gz
>   Size/MD5 checksum:   831189 226fdde5498c56288e777c7a697996e0
>
http://security.debian.org/pool/updates/main/o/openssh/openssh_3.3p1-0.0wood
y1.diff.gz
>   Size/MD5 checksum:33009 4850f4a167cb515cc20301288e751e27
> 
>   alpha architecture (DEC Alpha)
> 
>
http://security.debian.org/pool/updates/main/o/openssh/ssh_3.3p1-0.0woody1_a
lpha.deb
>   Size/MD5 checksum:   844556 7ef1518babcb185b5ef61fde2bd881c5
>
http://security.debian.org/pool/updates/main/o/openssh/ssh-askpass-gnome_3.3
p1-0.0woody1_alpha.deb
>   Size/MD5 checksum:33422 ba9145a70719500ba56940e79e2cba02
> 
>   arm architecture

Re: [SECURITY] [DSA-134-1] OpenSSH remote vulnerability

[Wichert Akkerman]

Previously Phillip Hofmeister wrote:
> Does this effect the daemon or the client?

Again we really have no information to base this on, but everything
points to a problem in the daemon (privsep does not help in the client).

> If it effects the daemon, is the potato version vulnerable?

I suspect so, we do not have the information to really confirm or deny
this. I would recommend restricting ssh access if possible and/or look
into an alternative like telnetd-ssl (make sure you use the -z secure
option to only allow SSL connections).

Wichert.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA-134-1

[Wichert Akkerman]

Previously Anthony DeRobertis wrote:
> $VENDOR says it's broken
> $VENDOR won't provide details
> $VENDOR says upgrade two minor releases
> $VENDOR says upgrading doesn't actually fix the problem
> $VENDOR says upgrading will break things
> Woody security update comes out before potato one.

Lovely situation, isn't it?

> That makes for the weirdest DSA I can remember.

Definitely. I really wish we could do more but the complete lack
of more information we have make things difficult. Backporting
OpenSSH 3.3p1 to to potato is also slightly complicated by missing
build dependencies, but we hope to have packages ready sometime
tomorrow.

> PS: With the Apache hole and then this, when was the last time 
> you got any sleep, Wichert?

This was my daytime, and most of the work was done by Daniel Jacobowitz.

Wichert.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

DSA-134-1

[Anthony DeRobertis]

$VENDOR says it's broken
$VENDOR won't provide details
$VENDOR says upgrade two minor releases
$VENDOR says upgrading doesn't actually fix the problem
$VENDOR says upgrading will break things
Woody security update comes out before potato one.

That makes for the weirdest DSA I can remember.

PS: With the Apache hole and then this, when was the last time 
you got any

sleep, Wichert?


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [SECURITY] [DSA-134-1] OpenSSH remote vulnerability

[Phillip Hofmeister]

Sowhat does this mean for us running potato on internet servers?

Does this effect the daemon or the client?

If it effects the daemon, is the potato version vulnerable?


Phil

On Mon, Jun 24, 2002 at 11:56:04PM +0200, Wichert Akkerman wrote:
> 
> Debian Security Advisory DSA-134-1   [EMAIL PROTECTED]
> http://www.debian.org/security/ Wichert Akkerman
> June 24, 2002
> 
> 
> 
> Package: ssh
> Problem type   : remote exploit
> Debian-specific: no
> 
> Theo de Raadt announced that the OpenBSD team is working with ISS
> on a remote exploit for OpenSSH (a free implementation of the
> Secure SHell protocol). They are refusing to provide any details on
> the vulnerability but instead are advising everyone to upgrade to
> the latest release, version 3.3.
> 
> This version was released 3 days ago and introduced a new feature
> to reduce the effect of exploits in the network handling code
> called privilege separation.  Unfortunately this release has a few
> known problems: compression does not work on all operating systems
> since the code relies on specific mmap features, and the PAM
> support has not been completed. There may be other problems as
> well.
> 
> The new privilege separation support from Niels Provos changes ssh
> to use a separate non-privileged process to handle most of the
> work. This means any vulnerability in this part of OpenSSH can
> never lead to a root compromise but only to access to a separate
> account restricted to a chroot.
> 
> Theo made it very clear this new version does not fix the
> vulnerability, instead by using the new privilege separation code
> it merely reduces the risk since the attacker can only gain access
> to a special account restricted in a chroot.
> 
> Since details of the problem have not been released we were forced
> to move to the latest release of OpenSSH portable, version 3.3p1.
> 
> Due to the short time frame we have had we have not been able to
> update the ssh package for Debian GNU/Linux 2.2 / potato yet.
> Packages for the upcoming 3.0 release (woody) are available for
> most architectures.
> 
> Please note that we have not had the time to do proper QA on these
> packages; they might contain bugs or break things unexpectedly. If
> you notice any such problems please file a bug-report so we can
> investigate.
> 
> This package introduce a new account called `sshd' that is used in
> the privilege separation code. If no sshd account exists the
> package will try to create one. If the account already exists it
> will be re-used. If you do not want this to happen you will have
> to fix this manually. 
> 
> 
> wget url
> will fetch the file for you
> dpkg -i file.deb
> will install the referenced file.
> 
> 
> Debian GNU/Linux 2.2 alias potato
> -
> 
>   Potato was released for alpha, arm, i386, m68k, powerpc and sparc.
> 
>   Package for potato are not available at the moment
> 
> 
> Debian GNU/Linux 3.0 alias woody
> -
> 
>   Woody will be released for alpha, arm, hppa, i386, ia64, m68k, mips,
>   mipsel, powerpc, s390 and sparc. Packages for m68k are not yet
>   available at this moment.
> 
> 
>   Source archives:
> 
> 
> http://security.debian.org/pool/updates/main/o/openssh/openssh_3.3p1-0.0woody1.dsc
>   Size/MD5 checksum:  751 2409524dc15e3de36ebfaa702c0311ea
> 
> http://security.debian.org/pool/updates/main/o/openssh/openssh_3.3p1.orig.tar.gz
>   Size/MD5 checksum:   831189 226fdde5498c56288e777c7a697996e0
> 
> http://security.debian.org/pool/updates/main/o/openssh/openssh_3.3p1-0.0woody1.diff.gz
>   Size/MD5 checksum:33009 4850f4a167cb515cc20301288e751e27
> 
>   alpha architecture (DEC Alpha)
> 
> 
> http://security.debian.org/pool/updates/main/o/openssh/ssh_3.3p1-0.0woody1_alpha.deb
>   Size/MD5 checksum:   844556 7ef1518babcb185b5ef61fde2bd881c5
> 
> http://security.debian.org/pool/updates/main/o/openssh/ssh-askpass-gnome_3.3p1-0.0woody1_alpha.deb
>   Size/MD5 checksum:33422 ba9145a70719500ba56940e79e2cba02
> 
>   arm architecture (Arm)
> 
> 
> http://security.debian.org/pool/updates/main/o/openssh/ssh_3.3p1-0.0woody1_arm.deb
>   Size/MD5 checksum:   653454 4b6553ed08622525c6f22e7dc488f7c6
> 
> http://security.debian.org/pool/updates/main/o/openssh/ssh-askpass-gnome_3.3p1-0.0woody1_arm.deb
>   Size/MD5 checksum:32636 902f862c07059cdccb2ece3147f66282
> 
>   hppa a