Bugtraq mailing list archives
CyberCash MCK 3.2.0.4: Large /tmp hole
From: sheldon_young () YAHOO COM (Sheldon Young)
Date: Wed, 12 Jan 2000 10:00:38 -0800
Manfuacturer: CyberCash (http://www.cybercash.com) Software: Merchant Connection Kit Version: 3.2.0.4 There is a serious security hole in the CyberCash Merchant Connection Kit version 3 due to inappropriate use of temporary files. The result is that local users are able to delete, corrupt and create files writable by the web server and prevent any credit card transactions from occuring. The basic problem is that in at least two places (CCMckLib3_2.pm and CCMckDirectLib3_2.pm) they do the following: my($tempfile) = "hash$$"; $tempfile =~ tr/A-Za-z0-9_//cd; $tempfile = $TMPDIR . "$tempfile.tmp"; # Input may be sensitive, so pipe it in... open(HASH,"| $computehash >$tempfile"); print HASH $signThis; print HASH "\r\n"; # force a flush close(HASH); # get the base64-encoded MD5 hash open(TEMP,"< $tempfile"); $hash = <TEMP>; chomp($hash); close(TEMP); # strip leading and trailing whitespace $hash = &Trim($hash); # clean up the temporary file unlink "$tempfile"; That is so full of holes I'm not even sure I need to enumerate them, but for those who don't read Perl: - Completely predictable temporary file names. - The open() the file two different times without check to see if it actually succeeded. - Creates a temporary file blindly in /tmp without bothering to account for the usual holes like symbolic links. - They DELETE the file without bothering to see if the open actually succeeded. The workaround is to not allow local users on the same machine as any credit card processing (may be difficult for web hosting companies), to not use the Perl API (no guarantee the same mistakes aren't made in the other APIs), or to fix the code. I'm lucky that I can choose the first option. I have been in contact with CyberCash merchange support several times over the past three months and have been completely unable to get any sort of adequate response. Their best answer was:
The hole describe is incorrect file permissions on the
web
server config files. Our code doesn't avoid the problem, but doesn't
help
in the exploit either. We should get rid of the temp files entirely in
the
next release of the MCK anyway, as we did in the IBCK. This isn't a bug. If the merchant has his system
properly
configured there is no security hole. In a future release of the MCK we
will
change the way the crypto is done so that temp files will not be used.
Ahem. Sheldon Young sheldon_young () yahoo com __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Current thread:
- Re: ICQ Buffer Overflow Exploit, (continued)
- Re: ICQ Buffer Overflow Exploit Simon Steed (Jan 13)
- Anyone can take over virtually any domain on the net... Thomas Reinke (Jan 11)
- Re: Anyone can take over virtually any domain on the net... Jon Lewis (Jan 13)
- Re: Anyone can take over virtually any domain on the net... Jeffrey Paul (Jan 13)
- Re: Anyone can take over virtually any domain on the net... Chris Adams (Jan 13)
- Re: Anyone can take over virtually any domain on the net... Shafik Yaghmour (Jan 13)
- Re: Anyone can take over virtually any domain on the net... Nick Lamb (Jan 15)
- Re: Anyone can take over virtually any domain on the net... Kurt Seifried (Jan 13)
- Blinding BIND to a moving domain D. J. Bernstein (Jan 12)
- Re: Blinding BIND to a moving domain Ken Gourlay (Jan 12)
- CyberCash MCK 3.2.0.4: Large /tmp hole Sheldon Young (Jan 12)
- Administrivia: ORBS Elias Levy (Jan 12)
- WebSitePro/2.3.18 is revealing Webdirectories Lark Lizerman (Jan 12)
- Re: Hotmail security hole - injecting JavaScript using <IMG Grahame Bowland (Jan 05)
- Re: Hotmail security hole - injecting JavaScript using <IMG Dustin Miller (Jan 05)