* * * * *

      “OMG! You're running server software older than two days! Pwned!”

I was just given a security scan compliance report, run by XXX XXXXXXXX
XXXXXXXX & XXXXXXXXXX XXXX on behalf of one of our customers, and it's rather
amusing at 502 pages in length.

The security company wanted a list of everything that is even remotely
associated with the customer's dedicated server that is publically accessible
via IP (Internet Protocol)—stuff like name servers, mail servers and routers.
Well, the customer's server handles everything except DNS (Domain Name
Service) and routing, so I sent along the IP address of the DNS servers and
the primary router here at The Company.

The security company did their scan, and sent along their 502 page report.

Ho ho ho.

There are five levels of vulnerabilities. One and two are in the “Well, we
don't like that these exist, but I suppose we'd get too many complaints if we
actually recommended that people be unable to use ping or traceroute, or
force people to forge WHOIS contact information” (heaven forbid anyone
wanting to trouble shoot networking issues). Think I'm kidding about levels
one and two? Here are some sample level one and two “vulnerabilities:”

* Web Server Supports HTTP (HyperText Transport Protocol) Request Pipelining
 [it's part of the HTTP protocol as specified in RFC-2616 (Request For
 Comment: Hypertext Transfer Protocol—HTTP/1.1) [1]]
* Mail Exchange (MX) Record Gathered from DNS Server [um … I suppose
 disabling of SMTP (Simple Mail Transport Protocol) entirely might be
 considered a Good Thing™, given the levels of spam, but people still use
 email, and this is part of the SMTP specification]
* SMTP Service Detected [at level two no less!]
* DNS Hierarchy of Target DNS Server Traced [just writing about these is
 causing my blood pressure to escalate—is this security company on Crack or
 something?]
* Host Names Found [oh dear we seem to actually have DNS PTR records!]
* Target Network Information [this means The Company is listed in the WHOIS
 database as owning the IP address. The fact that for any given publically
 routable IP address on the Internet someone somewhere owns said IP address
 has probably escaped this security company]

Levels three and four are in the “There exists a theorectical exploit that in
reality is impossible to actually exploit, but since it does exist, and the
fact that the server software you are running is older than twenty minutes
old, means we don't like it and therefore you don't pass. Please upgrade
immediately to the latest codebase; we don't care if it causes the server to
become inoperable (actually, that's a Good Thing™)—upgrade now!” And level
five is “**OH MY GOD THE INFOCAPALYPSE IS NIGH UPON YOU! YOU ARE PWNED! GET
AWAY FROM US YOU VENOMOUS CRETINS FOR EVEN THINKING OF RUNNING SERVER
SOFTWARE THAT IS OLDER THAN TWO DAYS!**”

Of course, I have issues with the report.

Okay, one of the three bazillion “vulnerabilities” on the customer's server,
at level “Infocapalypse” is the following:

> **Title:** Multiple Apache Web Server < 2.0.51 Vulnerabilities
>
> **Severity:** 5
>
> **Diagnosis:** There is an input validation issue in IPv6 literal address
> parsing which can result in a negative length parameter being passed to
> memcpy.
>
> A buffer overflow in configuration file parsing makes it possible for a
> local user to gain the privileges of a httpd child, if the server can be
> forced to parse a carefully crafted “.htaccess” file.
>
> A segfault in “mod ssl” can be triggered by a malicious remote server, if
> proxying to SSL (Secure Socket Layer) servers has been configured.
>
> A potential infinite loop in “mod ssl” can be triggered given particular
> timing of a connection abort.
>
> A segfault in “mod dav fs” can be remotely triggered by an indirect lock
> refresh request.
>
> **Consequence:** An attacker may get control of the server.
>

(Yes, that is one “vulnerability,” by the way)

Can you say “overboard?”

We don't run IPv6 on our network. Even if we were, this would most likely
cause the server to crash on startup (or at the worse, if trigger by a
directive in .htaccess, crash just that child process).

We don't proxy SSL servers. Even if we were, this would just crash that
particular request. Yes, it could lead to a denial of service attack, but
those are rather hard to guard against anyway.

We don't have mod_dav running. And again, even if it were, it's just a replay
of the above problem.

Of the two remaining “issues,” one sounds theoretical, and even if it were
possible, is just a (heh—“just a”) type of denial service attack. Hard to
gain control of a server that way (well, for certain values of “control” I
suppose).

That does leave the last “issue,” which is a valid issue, but one that's (in
my humble opinion) rather moot—if someone can place a carefully crafted
htacces file on the server, they already have access to the server!

Um … yeah.

I would also be more impressed if the report did not contain five duplicates
of this “issue.” And I don't mean because there are five different IP
addresses on the server—no, this was six instances reported for a single IP
address. I'm guessing that a 502 page security scan compliance report is more
impressive than a mere 302 page security scan compliance report.

In fact, of the 216 “vulnerabilities” listed for the customer's server, 129
were duplicates. Sure, some of them are interesting, but the sheer repetition
(and the silliness of some of them) lessens the impact for me. It makes
reading the report rather tedious, which in my mind, lessens the worth of
this 502 page report.

I just hope Smirk can calm down the customer.

[1] ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt

Email author at [email protected]