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
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 prot
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.
--
_
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
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 architectu
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? Contac
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
>>
* [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
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
a
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 pu
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 (p
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 s
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 i
"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 ha
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.
n
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 kn
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
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 a
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
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
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 thei
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
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 us
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
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,
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
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
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 r
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
> 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 pota
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
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
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 s
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
$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: W
:
>
> Debian Security Advisory DSA-134-1 [EMAIL PROTECTED]
> http://www.debian.org/security/ Wichert Akkerman
> June 24, 2002
>
>
>
&
36 matches
Mail list logo
