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

Buffer overflow in Solaris libc, ufsrestore, and rcp via LC_MESSAGES environmental variable.

**\[prev in list\] \[next in list\] \[prev in thread\] \[next in thread\]** 
**List:       bugtraq
Subject:    Re: Linux NLSPATH buffer overflow
From:       Alan Cox <alan () LXORGUK ! UKUU ! ORG ! UK>
Date:       1997-02-14 20:51:02
\[Download RAW message or body\]**

> I'm sorry if the information I'm going to tell about was already known, but
> I hope it wasn't...

Its known, its fixed in current setups

> It might be possible to exploit this hole remotely, if using a patched telnet
> client which would allow exporting large environment variable values. The
> overflow would happen at /bin/login startup then (somewhat like the famous
> LD\_PRELOAD exploit, but an overflow). I'm not sure of that though, there might
> be some restrictions on environment variables in telnetd.

Netkit 0.08/9 telnetd do not pass any environment variables,

> As for the fix, well, this is a hard one -- would require re-compiling libc,
> and statically linked binaries. To protect yourself against remote attacks,
> you could for example change the variable name to something different, with
> a hex editor (like /usr/bin/bpe), in /lib/libc.so.5, and ensure the exploit
> stopped working. Of course, this is only a temporary fix.

libc5.4 is immune, RedHat has been shipping the fixed libc5.3.12 for a long
time, and all the vendors I had security contacts for where told ages ago.
If they haven't fixed it then Im disappointed with them, they dont have
an excuse. That libc5.3.12 unpatched also has other fun bugs with buffer
overruns in libc some in the BSD stuff akin to the BSD bugs in rcmd() etc.

Alan

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

  

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

Tag

#sap