CyberCash MCK 3.2.0.4: Large /tmp hole

[sheldon_young () YAHOO COM (Sheldon Young)]

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