Does anyone know if the openssh exploit that 3.3 is supposed to not fix,
but do damage control for, is it still exploitable if you have set your
/etc/hosts.deny to deny all hosts, and then /etc/hosts.allow to only
allow from trusted ips.
In other words, if a malicious ssh request comes from
I was a little hasty in my first reply. It is a noted bug
(http://bugzilla.mindrot.org/show_bug.cgi?id=285)
Disabling compression will solve the problem on 2.2.x kernels.
(Compression no)
Hope that helps you.
On Mon, 2002-06-24 at 20:49, buggz wrote:
Does 3.3 work w/ 2.20 kernels ?
Jun
On Mon, 24 Jun 2002 23:00:46 -0500
Paul Baker [EMAIL PROTECTED] wrote:
In other words, if a malicious ssh request comes from an ip that is
already denied via tcp_wrapper support in ssh, will it still be able
to exploit OpenSSH 3.3?
We have no way of being sure, since the nature of the
On Monday, June 24, 2002, at 11:20 PM, David B Harris wrote:
We have no way of being sure, since the nature of the exploit and the
specifics aren't being told.
However, supposedly, you need to be able to talk to the sshd in order to
exploit it. So if nothing (or nothing malicious) can open a
On Mon, 24 Jun 2002 23:39:04 -0500
Paul Baker [EMAIL PROTECTED] wrote:
Does the tcp_wrapper use in openssh work that way? It's not like ssh
is running from inetd first being passed through tcpd. I'm just using
the builtin tcpwrapper support of openssh, so I would guess that that
means
On Tuesday, June 25, 2002, at 12:39 , Paul Baker wrote:
but potentially maybe someone could craft a malicious packet
that appears to come from one of the trusted ips??
SSH uses TCP, not UDP. In order for the kernel to pass any data
to OpenSSH, the following must happen:
REMOTE
On Tuesday, June 25, 2002, at 12:00 , Paul Baker wrote:
Does anyone know if the openssh exploit that 3.3 is supposed to
not fix, but do damage control for, is it still exploitable if
you have set your /etc/hosts.deny to deny all hosts, and then
/etc/hosts.allow to only allow from trusted
Previously Sean McAvoy wrote:
I was a little hasty in my first reply. It is a noted bug
(http://bugzilla.mindrot.org/show_bug.cgi?id=285)
Disabling compression will solve the problem on 2.2.x kernels.
(Compression no)
Actually our package contains a patch from Solar Designer to make
privsep
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.
Weee !
That works ! Cool, many tanx !
On 25 Jun 2002, Sean McAvoy wrote:
I was a little hasty in my first reply. It is a noted bug
(http://bugzilla.mindrot.org/show_bug.cgi?id=285)
Disabling compression will solve the problem on 2.2.x kernels.
(Compression no)
Hope that helps you.
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
Hi,
I have read several times, including on this list, that password
authentication with ssh does not send the password in clear text (it is
sent in the encrypted tunnel). This is confirmed by the ssh(1) man page:
If other authentication methods fail, ssh prompts the user for a
On Tue, 2002-06-25 at 15:35, Florent Rougon wrote:
But the default sshd_config in the openssh-3.0.2p1 package has a comment
indicating the contrary:
,
| # To disable tunneled clear text passwords, change to no here!
| PasswordAuthentication yes
`
and according to that comment,
On Tue, Jun 25, 2002 at 03:35:19PM +0200, Florent Rougon wrote:
Hi,
I have read several times, including on this list, that password
authentication with ssh does not send the password in clear text (it is
sent in the encrypted tunnel). This is confirmed by the ssh(1) man page:
If
Wichert Akkerman [EMAIL PROTECTED] writes:
Debian Security Advisory DSA-134-2 [EMAIL PROTECTED]
http://www.debian.org/security/ Wichert Akkerman
June 25, 2002
On Tue, 2002-06-25 at 15:57, Kruskal wrote:
Has anyone applied this update yet? I did so on a potato box, enabled
priv separation in the sshd config file and restarted sshd. I saw
that a user called sshd was created. However, when I ssh'ed in, I
didn't see any processes owned by sshd. In
I have prefered wait a real bugfixe and in waiting I have installed
telnetd-ssl and block all ssh traffic in the firewalls
On Tue, 2002-06-25 at 15:57, Kruskal wrote:
Wichert Akkerman [EMAIL PROTECTED] writes:
On Tue, Jun 25, 2002 at 02:37:12PM +0200, Wichert Akkerman remarked:
-BEGIN PGP SIGNED MESSAGE-
-
Debian Security Advisory DSA-134-2 [EMAIL PROTECTED]
http://www.debian.org/security/
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
Mark Janssen [EMAIL PROTECTED] writes:
On Tue, 2002-06-25 at 15:57, Kruskal wrote:
Has anyone applied this update yet? I did so on a potato box, enabled
priv separation in the sshd config file and restarted sshd. I saw
that a user called sshd was created. However, when I ssh'ed in, I
This one time, at band camp, Raymond Wood said:
Potato and Woody are both patched then. What is the recommended
course of action for those running Sid? Should Sid users
install the Woody patch, or is this a bad idea?
Thanks for all the hard work Debian Security people!
Cheers,
Raymond
[Raymond Wood wrote in newsgate.debian.security]
Potato and Woody are both patched then. What is the recommended
course of action for those running Sid? Should Sid users
install the Woody patch, or is this a bad idea?
Personally, I've dist-upgraded all woody and sid boxen I have, the sid
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, Jun 25, 2002 at 02:40:19AM -0400, Anthony DeRobertis wrote:
Note that to do (1), you must insure that the real machine does
not send a RST in response to the SYN|ACK. Ways to do this are
numerous; DoS attacks come to mind.
Or just use an unused IP
--
To UNSUBSCRIBE, email to
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, 2002-06-25 at 16:50, Rob Andrews wrote:
[Raymond Wood wrote in newsgate.debian.security]
Potato and Woody are both patched then. What is the recommended
course of action for those running Sid? Should Sid users
install the Woody patch, or is this a bad idea?
Personally, I've
On Tuesday, June 25, 2002, at 11:14 AM, Phillip Hofmeister wrote:
On Tue, Jun 25, 2002 at 02:40:19AM -0400, Anthony DeRobertis wrote:
Note that to do (1), you must insure that the real machine does
not send a RST in response to the SYN|ACK. Ways to do this are
numerous; DoS attacks come to
On Tue, 2002-06-25 at 18:27, Tycho Fruru wrote:
In the recommended config it would be something like /var/empty, not
writable by the sshd user. I don't have a system handy to verify
whether the package does the right thing here though.
The debian package chroots to the empty and root:root
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
On Tue, 25 Jun 2002 14:50:30 + (UTC)
Rob Andrews [EMAIL PROTECTED] wrote:
Oh, the package created an 'sshd' user, and set it's homedir to
$HOMEDIRS/sshd, but didn't create the homedir itself. Since there isn't any
PoC code to test this with, I don't know how the chroot will end up.
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
Unable to log onto secure sites.
Followed http://pandor etc directions
Got an index of / ~kitamd/morzilla without the ability to download
apt-get update or
apt-get install mozilla
What can you suggest?
Franky
On Tue, Jun 25, 2002 at 17:14:49 -0400, [EMAIL PROTECTED] wrote:
Unable to log onto secure sites.
Followed http://pandor etc directions
Got an index of / ~kitamd/morzilla without the ability to download
apt-get update or
apt-get install mozilla
What can you suggest?
Some
On Tue, Jun 25, 2002 at 05:14:49PM -0400, [EMAIL PROTECTED] wrote:
Unable to log onto secure sites.
Followed http://pandor etc directions
Got an index of / ~kitamd/morzilla without the ability to download
apt-get update or
apt-get install mozilla
What can you suggest?
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
The subject says it all... I'm in Spain, is it happening everywhere or
is it just the phone company folks messing again with the DSL?
Regards,
Pope
--
Luis Gómez Miralles
InfoEmergencias - Technical Department
Phone (+34) 654 24 01 34
Fax (+34) 963 49 31 80
[EMAIL PROTECTED]
PGP Public
The subject says it all... I'm in Spain, is it happening everywhere or
is it just the phone company folks messing again with the DSL?
No, it seems to be a world wide problem. I'm in Hong Kong and it is the same
to me:
Err ftp://security.debian.org woody/updates/main Packages
Could not
Jonas == Jonas Weismüller [EMAIL PROTECTED] writes:
The subject says it all... I'm in Spain, is it happening everywhere
or is it just the phone company folks messing again with the DSL?
Jonas No, it seems to be a world wide problem. I'm in Hong Kong and it
Jonas is the same to me:
Jonas Err
51 matches
Mail list logo
