Security
Headlines
HeadlinesLatestCVEs

Headline

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

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.

CVE
#vulnerability#web#linux#perl#auth#sap

[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 [email protected] * 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” [email protected] To: [email protected] 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: Latest News

CVE-2023-50976: Transactions API Authorization by oleiman · Pull Request #14969 · redpanda-data/redpanda
CVE-2023-6905
CVE-2023-6903
CVE-2023-6904
CVE-2023-3907