There is a bug in the Crypt::ECB module that affects the way it processes blocks of data. It appears that Crypt::ECB incorrectly processes the last block of data if it contains a singe ASCII "0". This has been tested using the Blowfish, Rijndael, TripleDES, DES, and IDEA algorithms. Below is some proof-of-concept code to demonstrate the problem. The problem is produced where the plain-text data length is one more than ((n % 8) == 0). I have not tested the Crypt::CFB or Crypt::OFB modules which I believe are based on the Crypt::ECB module.
Plain-text data examples:
0
123456780
abcdefgh0
12345678123456780
ABCDEFGHabcdefgh0
1234567812345678123456780
ABCDEFGHabcdefgh123456780
... and so on...
Included below is a patch that corrects the problem in the Crypt::ECB module. I have attempted to contact the author, however, the email address in the module appears to be dead. I have also posted this problem on one of the CPAN bug sites.
I don't believe there is a security vulnerability here other than mechanisms that use the Crypt::ECB module to encode passwords will produce incorrect results with specific plain-text data sets. Um... I guess that is a security vulnerability in that there would be colliding passwords.
Thanks
- Bennett
Proof-of-Concept code:
#!/usr/local/bin/perl
use Crypt::ECB;
my $cipher = "Blowfish";
my $key = "pb25YTt7d5b55711fd50bffcec4058d3e6c86bfc4c796bec2249b447";
my $plain = "12345678123456780";
my $crypt = Crypt::ECB->new;
$crypt->padding(PADDING_AUTO);
$crypt->cipher($cipher) or die $crypt->errstring;
$crypt->key($key);
printf "Plain = '%s'\n", $plain;
my $enc = $crypt->encrypt_hex($plain);
printf "Encrypted = '%s'\n", $enc;
my $dec = $crypt->decrypt_hex($enc);
printf "Decrypted = '%s'\n", $dec;
Plain-text data examples:
0
123456780
abcdefgh0
12345678123456780
ABCDEFGHabcdefgh0
1234567812345678123456780
ABCDEFGHabcdefgh123456780
... and so on...
Included below is a patch that corrects the problem in the Crypt::ECB module. I have attempted to contact the author, however, the email address in the module appears to be dead. I have also posted this problem on one of the CPAN bug sites.
I don't believe there is a security vulnerability here other than mechanisms that use the Crypt::ECB module to encode passwords will produce incorrect results with specific plain-text data sets. Um... I guess that is a security vulnerability in that there would be colliding passwords.
Thanks
- Bennett
Proof-of-Concept code:
#!/usr/local/bin/perl
use Crypt::ECB;
my $cipher = "Blowfish";
my $key = "pb25YTt7d5b55711fd50bffcec4058d3e6c86bfc4c796bec2249b447";
my $plain = "12345678123456780";
my $crypt = Crypt::ECB->new;
$crypt->padding(PADDING_AUTO);
$crypt->cipher($cipher) or die $crypt->errstring;
$crypt->key($key);
printf "Plain = '%s'\n", $plain;
my $enc = $crypt->encrypt_hex($plain);
printf "Encrypted = '%s'\n", $enc;
my $dec = $crypt->decrypt_hex($enc);
printf "Decrypted = '%s'\n", $dec;
Patch:
###
### Diff for ECB fix (output from diff -u)
###
### Test Data:
### Plain: ILlW1nr30
### Key: pb25YTt7d5b55711fd50bffcec4058d3e6c86bfc4c796bec2249b447
### Pad: AUTO
###
--- ECB.pm 2000-12-23 13:16:38.000000000 -0500
+++ ECB2.pm 2004-12-06 12:45:23.000000000 -0500
@@ -1,4 +1,4 @@
-package Crypt::ECB;
+package Crypt::ECB2;
# Copyright (C) 2000 Christoph Appel, cappel (at) debis (dot) com [email concealed]
# see documentation for details
@@ -274,7 +274,7 @@
$crypt->{Mode} = '';
$crypt->{buffer} = '';
- return '' unless $data;
+ return '' unless length($data) > 0;
my $cipher = $crypt->_getcipher;
[ reply ]