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.
--
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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 *
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
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
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
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
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 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
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
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
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
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
:
Debian Security Advisory DSA-134-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Wichert Akkerman
June 24, 2002
Package: ssh
Problem type
$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:
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
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
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
33 matches
Mail list logo
