Unauthenticated Flaws in Network Protocols

Arguably the most famous bug in this class is the bug exploited by the SQL Server “Slammer” worm. The SQL
Server Resolution Service operates over a UDP protocol, by default on port 1434. It exposes a number of
functions, two of which were vulnerable to buffer overflow issues (CAN-2002-0649). These bugs were
discovered by David Litchfield of NGS. Another SQL Server problem in the same category was the “hello”
bug (CAN-2002-1123) discovered by Dave Aitel of Immunity, Inc., which exploited a flaw in the initial
session setup code on TCP port 1433.

Oracle has not been immune to this category — most recently, David Litchfield found an issue with
environment variable expansion in Oracle’s “extproc” mechanism that can be exploited without a username
or password (CAN-2004-1363). Chris Anley of NGS discovered an earlier flaw in Oracle’s extproc
mechanism (CAN-2003-0634) that allowed for a remote, unauthenticated buffer overflow. Mark Litchfield
of NGS discovered a flaw in Oracle’s authentication handling code whereby an overly long username
would trigger an exploitable stack overflow (CAN-2003-0095). David Litchfield also found a flaw in
DB2’s JDBC Applet Server (no CVE, but bugtraq id 11401) that allows a remote, unauthenticated user
to trigger a buffer overflow.

The best way to defend yourself against this class of problem is first, to patch. Second, you should
attempt to ensure that only trusted hosts can connect to your database servers, possibly enforcing
that trust through some other authentication mechanism such as SSH or IPSec. Depending on the role
that your database server is fulfilling, this may be tricky. Another possibility for defense is to
implement an Intrusion Detection System (IDS) or an Intrusion Prevention System (IPS). These kinds
of systems have been widely discussed in security literature, and are of debatable value. Although
an IDS can (sometimes) tell you that you have been compromised, it won’t normally prevent that
compromise from happening. Signature-based IDS systems are only as strong as their signature
databases and in most cases signatures aren’t written by people who are capable of writing
exploits, so many loopholes in the signatures get missed.

“True anomaly” IDS systems are harder to bypass, but as long as you stick to a protocol that’s
already in use, and keep the exploit small, you can usually slip by. Although some IDS systems
are better than others, in general you need an IDS like you need someone telling you you’ve
got a hole in the head. IDS systems will certainly stop dumber attackers, or brighter attackers
who were unlucky, so they may be worthwhile provided they complement — and don’t replace — skilled
staff, good lockdown, and good procedures. IPS systems, on the other hand, do prevent some classes
of exploit from working but again, every IPS system the authors have examined can be bypassed with
a little work, so your security largely depends on the attacker not knowing which commercial IPS
you’re using. Someone may bring out an IPS that prevents all arbitrary code execution attacks at
some point, which would be a truly wonderful thing. Don’t hold your breath waiting for it, though.


, , , , , , , , , , , ,

  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: