mod_cgid in Apache before 2.0.48, when using a threaded MPM, does not properly handle CGI redirect paths, which could cause Apache to send the output of a CGI program to the wrong client.

CVE-2003-0789

lpd daemon (in.lpd) in Solaris 8 and earlier allows remote attackers to execute arbitrary commands via a job request with a crafted control file that is not properly handled when lpd invokes a mail program. NOTE: this might be the same vulnerability as CVE-2000-1220.

**\[prev in list\] \[next in list\] \[prev in thread\] \[next in thread\]** 
**List:       bugtraq
Subject:    Solaris LPD Exploit (fwd)
From:       Dave Ahmad <da () securityfocus ! com>
Date:       2001-08-31 22:08:09
\[Download RAW message or body\]**

Hey,

The exploit that was attached to this message cannot be distributed..
so below is the original message sent to BUGTRAQ without the exploit.

From the exploit:

/\*
 \* remorse
 \* Solaris 8 in.lpd remote root exploit
 \* by ron1n <shellcode@hotmail.com>
 \* July 2001
 \*
 \* Written for 7DFB/TESO members and friends. Private, do not distribute
 \* negligently, etc. etc. An unpublished vulnerability is exploited. I think
 \* this is what they call 0day warez.
 \*
 \* This is not the ISS hole -- that one doesn't seem to be exploitable on the
 \* SPARC architecture. I spent a week studying all of the lp binary and library
 \* code trying to find a nice overflow that would be exploitable on SPARC. This
 \* is the best I could come up with though. I'm disappointed because it's very
 \* similar to the old SNI/NAI BSD lpd vuln and the l0pht/@stake Linux lpd vuln.
 \*
 \* There are no printer conditions that have to be met. If the system happens
 \* to be running in.lpd, consider it owned. It can be a noisy attack; other
 \* than possible syslog locations, evidence will exist under /var/spool/lp/tmp,
 \* /var/spool/lp/requests, and the mail spool directory (/tmp).
 \*
 \* The exploit targets four programs: in.lpd, lpsched adaptor, /bin/mail, and
 \* sendmail. Obviously there are going to be differences among Solaris releases
 \* and individual configurations. For instance, the Solaris 7 version of in.lpd
 \* doesn't have IPv6 support like the Solaris 8 version does, so if your IP
 \* address doesn't reverse-resolve, in.lpd will create a different directory
 \* on each release. I've handled this now in case I do a rewrite, but Solaris 7
 \* has other issues that need to be investigated. Solaris 2.6 looks even worse.
 \* If someone hooks me up with source code, I'll try to add 7 and 2.6 support.
 \*
 \* If you're not getting results, try playing around with some command line
 \* switches or some files in the exploit tarball, particularly 'script'. The
 \* system's responses, or lack thereof, can tell you everything you need for
 \* a successful exploitation.
 \*
 \* Now you too can sleep well at night knowing that there are still ways to
 \* compromise a Solaris box remotely without relying on Sun's rpc nightmare.
 \*
 \* "Something about you is very wrong..."
 \*/

Dave Ahmad
Security Focus
www.securityfocus.com

---------- Forwarded message ----------
From: "Ricky Vludmore" <ricky2k@anonymous.to>
To: bugtraq@securityfocus.com
Subject: Solaris LPD Exploit

\[This is allegedly for an unknown vulnerability.\]

I have attached the exploit that was used against me
and then sent to me as a result of my Incidents posts.
The swarm of me-too emails leads me to believe this
is being actively exploited with the public being
none the wiser. The tar content times and the
author's timestamp place it at around two months
old.

I can only guess at the intentions for trying to keep
this below the surface. The overall depressive tone of the
exploit is as unnerving as the author's up-beat attitude
toward system intrusion, but I will admit that the author
seems to hint at deeper motives. Either way, the more
productive and mature thing to do would have been to
inform the public so that end users aren't left in the
cold with these matters.

Two people asked if the system that was compromised is x86
or sparc. It's a sparc.

In reference to:

http://archives.neohapsis.com/archives/incidents/2001-08/0417.html
http://archives.neohapsis.com/archives/incidents/2001-08/0425.html

And a final post sent earlier:

>  About four hours ago I received a post from an
>  individual who claimed to have acquired exploit
>  source for this \_\_unknown\_\_ vulnerability on the
>  "ircnet chat network" about a week ago. He/she
>  then sent me a copy upon request, saying that
>  he/she witnessed it being used by a shady
>  individual in an exchange involving this and
>  another \_\_unknown\_\_ hole in a Solaris routing
>  daemon (luckily I don't run one of those!).
>
>  I now have a copy of the exploit. Haven't tried it
>  against a patched system for that (other) printer
>  bug. I somehow managed to get it working against
>  my (currently) unpatched system.
>
>  I couldn't read a line of C if my life depended on
>  it but the comments say it's an unpublished
>  hole and that it's not the ISS one (apparently
>  they were the guys who found this other printer
>  bug). I tried searching for it in a search engine.
>  No results.
>
>  I feel it's important that the public catch wind
>  of this exploit..
>
>  securityfocus contacts? bugtraq? sun?


------------------------------------------------------------
This email was sent through the free email service at http://www.anonymous.to/
To report abuse, please visit our website and click "Contact Us."

**\[prev in list\] \[next in list\] \[prev in thread\] \[next in thread\]** 

  

Configure | About | News | Add a list | Sponsored by KoreLogic

CVE-2001-1583: 'Solaris LPD Exploit (fwd)' - MARC

Denial of service in WU-FTPD via the SITE NEWER command, which does not free memory properly.

CVE-1999-0880: IBM X-Force Exchange

Cfingerd with ALLOW_EXECUTION enabled does not properly drop privileges when it executes a program on behalf of the user, allowing local users to gain root privileges.

CVE-1999-0813: IBM X-Force Exchange

A network intrusion detection system (IDS) does not properly reassemble fragmented packets.

CVE-1999-0602

The ARP protocol allows any host to spoof ARP replies and poison the ARP cache to conduct IP address spoofing or a denial of service.

Tag

#perl