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_youngat_private __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:27:54 PDT