[gentoo-security] [Fwd: [Full-Disclosure] iDEFENSE: Upcoming OpenSSH Security Advisory Announcement]

[Paul Cassell]

Heads up.

-----Forwarded Message-----
From: Richard Johnson <thief@×××××××.org>
To: full-disclosure@××××××××××××.com, bugtraq@×××××××××××××.com, vuln-dev@×××××××××××××.com, vulnwatch@×××××××××.org, misc@×××××××.org
Subject: [Full-Disclosure] iDEFENSE: Upcoming OpenSSH Security Advisory Announcement
Date: Mon, 03 May 2004 11:51:12 -0400


iDEFENSE Security Advisory 05.03.04:
http://www.idefense.com/advisory/05.03.04.txt
Upcoming OpenSSH Preauthentication Vulnerability Announcement
May 3, 2004

There is an upcoming OpenSSH vulnerability that we're working on with
the OpenBSD Crew.  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 for immediate root access. 

OpenSSH 3.3p was released a few years 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.8 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?  Being immune from at least one
remote bug is worth broken functionality, especially when the software
suffers from additional remote bugs.

3.8 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.  OpenSSH developers are swamped enough without trying to 
support the myriad of PAM and other issues which exist in various 
systems.  For more information regarding the OpenBSD Crew's struggle 
with PAM issues, please read: 
  http://www.openssh.com/txt/sshpam.adv

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.  Less vulnerable is better than more vulnerable, and we 
hope that someday the OpenBSD team can make things not vulnerable.

Threat elimination is more important than threat reduction, after all.

Apparently the OpenBSD Crew has been trying to warn vendors about 3.8
and the need for privs sep to be in use.  Since priv sep has existed 
for many years, and still is not used in 100% of deployed OpenSSH
installations, the world is doing this marvelous team of cryptography
experts and emerging mediocre programmers a world of discredit.  Some
developers, like Alan Cox, have reprotedly gone even 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 that Theo "might be feeding everyone a trojan". The official
OpenBSD Crew's response to this allegation can be seen here:
  http://www.openssh.com/txt/sshpam.adv

HP's representative has thusfar been downright rude, and we anticipate
that he will be removed from his position at the company in the near 
future for the negative attention that he is bringing to the company, 
and the lack of lucrative security PRODUCT and RESEARCH to the market.

Only the Solar Designer seems to think priv sep is a good idea, since 
historically he has been fond of developing security solutions
following known flawed models in the hopes of making exploitation of
security issues harder but not impossible, putting security back into
the hands of hackers and out of the hands of scriptkids and security 
consultants.

iDEFENSE recommends either using OpenBSD, Openwall Linux (Owl), or
Microsoft Windows.  All other operating systems are insecure.

So, if vendors would JUMP and get it working better, and send the 
OpenBSD Crew patches IMMEDIATELY, we can perhaps make a better 3.9 
release on Friday which supports all systems better.  So please send
patches to them IMMEDIATELY so progress can be made.  Then on Tuesday
or Friday the complete bug report with patches (and year old exploits,
we are sure) will hit BUGTRAQ(tm).

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.

If you doubt the sincerity of this claim, please review the following
case study and included references to the security of a privilage 
separation enabled open secure shell daemon's unbreakable status.
  http://www.phrack.org/phrack/60/p60-0x06.txt


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.8 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.

We would urge the OpenBSD Crew to remake the OpenSSH Security page
( http://www.openssh.com/security.html ) to make it less confusing. 
It would serve the public interest much better if the page listed 
specifically what versions are affected by which bugs, making it clear
which versions bugs were introduced in, and which versions said bugs 
have been fixed in.  The current listing is too difficult to process,
and listing what versions are no longer vulnerable to a particular 
known issue seems silly, since one would hope that the most recent
available version of a security PRODUCT would not suffer from any 
published and widely known security problems.

If you or your organization would like to purchase advanced details
of this vulnerability, please contact sales@××××××××.com with your
inquiry.

We at iDEFENSE would like to thank Kurt Seifried, consultant and 
"OUTSIDE_INTEL" operative/analyst (and SECURITY EXPERT) for all his
hard and profound work for us.  Also we would like to applaud him for
his brilliant work on translating the English translations of the CORE
Impact documentation to better English; a most impressive addition to
any resume is being able to brag of being a contractor for multiple
goverment contractors, because frankly - he is just that damn good.

           ______________________________________ 
          < Work for iDEFENSE and become famous! >
           -------------------------------------- 
                   \                _
                    \              (_)
                     \   ^__^       / \
                      \  (oo)\_____/_\ \
                         (__)\       ) /
                             ||----w ((
                             ||     ||>> 

iDEFENSE is a global security intelligence company that proactively
monitors sources throughout the world from technical vulnerabilities
and hacker profiling to the global spread of viruses and other *yawn*
delicious code.  Our security intelligence services provide decision
makers, frontline security professionals and network administrators
with timely access to actionable intelligence and decision support on
cyber-related threats.  For more information, visit our flash enabled
interweb portal at http://www.idefense.com.
-- 
Paul Cassell


--
gentoo-security@g.o mailing list