Helix Universal Server 9 and earlier versions (RealSystem Server 8, 7 and RealServer G2) are vulnerable to a root exploit when certain types of character strings appear in large numbers within URLs destined for the Server's protocol parsers.
2dbb8dceb018ef54a3e9f64fe191da489067b6b3aa66be81d8e731a9d1ec9d48<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Dailydave] Real security information is hard to come by
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:dailydave%40lists.immunitysec.com?Subject=%5BDailydave%5D%20Real%20security%20information%20is%20hard%20to%20come%20by&In-Reply-To=">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="000029.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Dailydave] Real security information is hard to come by</H1>
<B>dave at immunitysec.com</B>
<A HREF="mailto:dailydave%40lists.immunitysec.com?Subject=%5BDailydave%5D%20Real%20security%20information%20is%20hard%20to%20come%20by&In-Reply-To="
TITLE="[Dailydave] Real security information is hard to come by">dave at immunitysec.com
</A><BR>
<I>Mon Aug 25 09:04:51 EDT 2003</I>
<P><UL>
<LI>Previous message: <A HREF="000029.html">[Dailydave] High ports are fun too.
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#30">[ date ]</a>
<a href="thread.html#30">[ thread ]</a>
<a href="subject.html#30">[ subject ]</a>
<a href="author.html#30">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>Before you read this, I recommend you type "man memfrob" and "man strfry"
on your nearest Linux system. I had no idea Linux libC had so many inside
jokes. I think it says a lot about the character of the system.
In other news, Real was finally told about my HelixServer remote, after a
copy of CANVAS leaked (from <A HREF="http://www.immunitysec.com/mailman/listinfo/dailydave">tangy at s-ec.com</A>).
<A HREF="http://www.service.real.com/help/faq/security/rootexploit082203.html">http://www.service.real.com/help/faq/security/rootexploit082203.html</A>
The following code is where the bug is. Can you see it?
ServRegKey::ServRegKey(const char* pszKey, RegistryMemCache* pMemCache,
char chDelim)
: m_pRegMemCache(pMemCache)
{
if (!pszKey || !*pszKey)
{
return;
}
m_pCurrPtr = pszKey;
// We have to go through this two step process because of a problem with
// the 16 bit compiler.
char* pTmpPtrs2[1024]; <---egads!
const char** pTmpPtrs = (const char**)pTmpPtrs2;
pTmpPtrs[0] = pszKey;
/*
* loop to find out how many levels are there in this key string
* pointers in the string to the various sub-strings are stored in
* a temporary array, which will then be xferred to a dynamic array
* stored along with the key. this will speed up the sub-string
* operations done later.
*/
m_nLevels = 1;
m_nSize = 1;
while (*m_pCurrPtr)
{
if (*m_pCurrPtr == chDelim)
{
if (m_pCurrPtr > pszKey)
{
pTmpPtrs[m_nLevels] = m_pCurrPtr;
m_nLevels++;
}
}
m_nSize++;
m_pCurrPtr++;
}
pTmpPtrs[m_nLevels] = m_pCurrPtr;
. . .
What happens here is that an array of pointers to your string is added to
every time a "/" is found. So enough ../../ action and the return address
is changed to point to an area of memory you control on the heap.
Notice that there is no magic number associated with this bug - it's
extremely reliable. In fact, if you gave it enough time and energy, you
could finally have a chance to use your multiple-platform shellcode. I
didn't bother though, since you can make an OPTIONS query to get the exact
version and platform from any remote RealServer.
If you were one of the few people who was compiling your Helix Server from
scratch (they offer it via a Open Source license) then you can easily
patch this bug and be done with it, without removing .so files or doing
anything like that. If you have to wait for Real to send you a new binary,
then you'r e stuck. It's highly exploitable on x86 or another unaligned
archetecture (e.g. Linux, FreeBSD, and Win32), and very difficult to
exploit on SPARC or another word aligned system. (If that didn't make
sense to you, just think "Linux, Windows, and FreeBSD GOOD. Solaris, Irix,
Tru64 BAD).
Since I'm not "all about the advisories." and, in fact I think advisories
are largely a waste of time, I normally would not have said anything. But
this RealServer bug is almost poetic and since it's on its deathbed now, I
felt it was time to share a bit of the family photographs of it as a naked
kid and wearing braces going to the prom and stuff.
Note that you didn't hear any of this stuff from Real, or from anyone
reading <A HREF="http://www.immunitysec.com/mailman/listinfo/dailydave">Incidents at securityfocus.com</A>, or from anyone who downloaded the
pirated CANVAS that's been floating around. Partly that's respect, since
it's considered lame in the community to steal other people's bugs and
report them (although it does happen). Part of it is stupidity and
lazyness, since it takes time to figure out what a bug actually is. Part
of that is a natural capitalist effect that I think needs more attention:
Real's a pretty big company. And in many cases has hired various security
consulting firms - the firms most likely to say they are independent
sources of security information - to do consulting work. Even in the case
that they haven't hired these companies, these companies know that they
could at any time be trying to write up a statement of work for Real. So
none of them can afford to get on Real's bad side.
Now, telling the public the truth about a bug in Real's product is going
to seriously piss Real off. Real is running a PR campaign here. They can't
say "Here's a perfectly reliable bug in our code that affects every modern
version that was found in ten seconds (actual clocked time!) with SPIKE
which we didn't even bother to run." That doesn't play well among the
Fortune 500 companies that Real has listed as Target Accounts.
What I'm saying is that in effect, the software industry has enjoined the
security community to join them as "partners." This has been so successful
that various portions of the security community have put out papers
calling for legislative action to restrict vulnerability information
flowing to the public. In effect, they are as bad as the music industry,
asking that only their business model be legally correct. They hide this,
as does the music industry, in terms of morals, ethics, and "correctness."
<A HREF="http://www.sbq.com/sbq/vuln_disclosure/sbq_disclosure_liability.pdf">http://www.sbq.com/sbq/vuln_disclosure/sbq_disclosure_liability.pdf</A>
Also on that website:
"To that end, and in response to customer requests, Microsoft engaged
@stake, a leading independent security consulting firm, to perform a
competitive security analysis of the .NET Framework versus IBM’s WebSphere
implementation of the J2EE framework."
<A HREF="http://www.atstake.com/research/reports/eval_ms_ibm/">http://www.atstake.com/research/reports/eval_ms_ibm/</A>
I do not think "independence" means what they think it means. Sponsored
studies such as this one, especially with such subjective rating schemes,
do not produce valid results and would not be taken seriously in any
industry.
And I would go further to say that when your company (and this is true for
all of the major "independent" security consulting companies) is reliant
on the software industry for a large part of your income, NONE of your
tests for other customers can have significant valid results, when a valid
result would harm your business position with a software vendor (which is
practically every time).
This is a problem that I think people are slowly wising up to in this
industry. You either work for the software industry, or you work for your
other customers. You cannot do both.
Dave Aitel
Immunity, Inc.
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="000029.html">[Dailydave] High ports are fun too.
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#30">[ date ]</a>
<a href="thread.html#30">[ thread ]</a>
<a href="subject.html#30">[ subject ]</a>
<a href="author.html#30">[ author ]</a>
</LI>
</UL>
<hr>
<a href="http://www.immunitysec.com/mailman/listinfo/dailydave">More information about the Dailydave
mailing list</a><br>
</body></html>
© 2024 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed