Re: Perl / Oracle Vuln. New or Not?

[Lincoln Yeoh <lyeoh () POP JARING MY>]

At 06:52 PM 12/7/00 -0500, Simon Kenton wrote:
> System:
> Solaris 2.6 running Netscape Enterprise Server, Perl5, and Oracle.
>
> Symptoms:
> Inputting 40,001 or more characters into any form field causes an application
> error.
>
> When  40,001+ characters, are entered into a textbox field and submitted via
> the form, the web server displays the directory structure of the server, the
> version of Perl running, and divulges the fact that Oracle is installed on
the
> system.  This gives an attacker information about a system that only system
> administrators have a legitimate need to know.  This information could
help an
> attacker craft a successful attack against a server with this vulnerability.
> When 80,001+ characters are submitted through the form, the Perl script dies,
> and the web server displays a ‘page unavailable’ error.  Either of these
> conditions may be causing a buffer overflow condition giving a further
> opportunity for an attacker to compromise the server.
>
> Cause:
> The HTML form linked to foo.pl does not limit the number of character that it
> passes to the foo.pl.  The Perl script does not does not limit the size of
> data it will accept by automatically truncating data input through the form

> From what is mentioned, it seems to me that the problems/symptoms/info
exposure are mainly because the perl script was not written securely. I'm
not even sure that the DBI or DBD is experiencing a buffer overrun. It
could just be giving an ugly but expected error message and throwing an
exception which is not handled by the script.

The script should be filtering all input so that it can cope. Then it
should filter AND format/quote all its outputs accordingly so that others
can cope (browsers, databases, other external programs).

Also if you are using the CGI.pm module you can define:
$CGI::POST_MAX=$maxbytestoallow;

That should help deal with huge stuff being POSTed to you. After that you
must still filter the stuff to make sure things are ok. The POST_MAX is
just another line of defense.

The fact that you are seeing the directory structure etc is also because of
the script.

When there is an error, the script should just say a few things depending
on whose fault it is.

1) Sorry, it's our fault - can't connect to database, can't save changes,
complete transaction etc).
2) It's your fault - fill in the form properly, and stop messing around.
3) Doh, something went really wrong, and I don't know who to blame.
4) Nothing - if can't even say a single thing properly, don't.

If desired (e.g. LOG_LEVEL=whatever), the details of the errors should be
filtered, formated and quoted accordingly and sent to the correct log for
the admin/developer to look at. No point displaying the minute details to
the public.

Another thing. You mentioned one of the causes being the html form not
limiting stuff. That is a risky perspective. Do NOT rely on HTML
forms/pages to limit the characters/fields/options/whatever that are passed
to foo.pl. People can always create their own forms and submit them with
the proper HTTP_REFERER, etc values too. The field sizes in the forms (and
icky javascript) are just for the user's _convenience_. They are just hints
so the user doesn't bother entering 200 characters in a 30 char field.

At the moment it all points to foo.pl being the problem. Any info on
foo.pl? Vendor etc?

Cheerio,
Link.