lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
From: booger at unixclan.net (security snot)
Subject: OpenSSH again - not really.

Surely you must be joking?  You're sounding sillier that Marty, when he
claimed that Sourcefire.com boxes couldn't have been compromised from his
shellbox, when people logged in to his corporate network from the
compromised server.

Do you honestly think privsep lets you get away with the "don't worry"
state of mind?

 http://www.phrack.org/phrack/60/p60-0x06.txt

So, after reading that, how confident are you with mechanisms like
privsep?  Is an "unprivilaged" jail'd/chroot'd environment really going to
let your box stay secure?  Do you think that not having access to write to
the filesystem will prevent code from being run that will hand over
instant root access?  If so you haven't seen COREST's patented
implementation of rpc/mosix, or really understand the idea that
"shellcode" isn't limited to simple tasks like executing a shell.

Which leads me to believe, you don't really know what you're talking
about.

So, what prevents that from happening?  Please don't say systrace; you'll
only look like more of an idiot.  So, maybe, do say systrace so the rest
of us can sit back and laugh at you.  At least, those of us who are clued.

Also, even if something like systrace did work, how does that prevent
other types of lesser-known bugs from being abused to gain further access
to the system, such as various hardware flaws[1]?

They don't.

So, go ahead and tell people PUT THEIR FUCKING FAITH IN OPENBSD (AND
THEIR SUPERSECURESHELL) THE  PROACTIVELY SECURE OPERATING SYSTEM WITH ONLY
FOUR REMOTE ROOT HOLES PUBLISHED IN ONE WEEK and to NOT WORRY BE HAPPY
PRIVSEP WILL SAVE YOU.

You're one of those people who won't update right away, because you think
you've got some magical window of time to do so, before unskilled
scriptkids figure out how to write an exploit for a publically disclosed
bug (general turnaround is a few days before the official release, since
they're all on the CERT and atstake lists - run by other geniuses such as
yourself).

Of course, you're also likely one that thinks patching is proactive
anyways, since you don't understand that vulnerabilities such as the
recent buffer mismanagment bug in OpenSSH have been abused widely in the
wild for nearly a year.

Then again, I'm sure privsep saved your life more than once.  More likely
you're the kind of guy who got hacked because you had sadmind running on a
Solaris box somewhere, and didn't bother to read the manpage that
explained that you need to reconfigure it to a more secure setting to
avoid the issue recently brought back into light by iDefense.

- booger

[1] There has been research by multiple entities concerning the abuse of
hardware bugs and their ramifications in terms of host exploitation.  Due
to my NDA, and my pledge to friends who have done similar research, I
cannot discuss any details concerning the matter, so just go ahead and
ignore me and claim that statement was some sort of trolling attempt.

-----------------------------------------------------------
"Whitehat by day, booger at night - I'm the security snot."
- CISSP / CCNA / A+ Certified - www.unixclan.net/~booger/ -
-----------------------------------------------------------

On Tue, 23 Sep 2003, Kurt Seifried wrote:

>  It looks possibly exploitable, but it needs privsep disabled. Many vendors
> now enable privsep by default (in my opinion if a vendor does not or can not
> enable privsep by default they have a misconfigured/broken OpenSSH package).
> The workaround is pretty trivial, make sure the following line occurs in
> your sshd config file:
>
> UsePrivilegeSeparation yes
>
> On recent Red Hat Linux versions and many others this is the default. You
> can check that privsep is working, log in via ssh and do a process listing,
> for each ssh connection you should see a pair of processes:
>
> root     32624  0.0  0.1  6752 1916 ?        S    16:06   0:00
> /usr/sbin/sshd
> seifried 32626  0.0  0.2  6776 2156 ?        R    16:06   0:00
> /usr/sbin/sshd
>
> or
>
> root     28354  0.0  0.1   372  1008 ??  Is     3:43PM    0:00.03 sshd:
> seifried [priv] (sshd)
> seifried 15019  0.0  0.1   416   912 ??  S      3:43PM    0:00.85 sshd:
> seifried@...p0 (sshd)
>
> As opposed to just one process running as root. Use privsep, be happy, don't
> worry.
>
> Kurt Seifried, kurt@...fried.org
> A15B BEE5 B391 B9AD B0EF
> AEB0 AD63 0B4E AD56 E574
> http://seifried.org/security/
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ