1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
|
Perl Module Security Advisory
========================================================================
CVE-2025-2814 CPAN Security Group
========================================================================
CVE ID: CVE-2025-2814
Distribution: Crypt-CBC
Versions: from 1.21 through 3.04
MetaCPAN: https://metacpan.org/dist/Crypt-CBC
Crypt::CBC versions between 1.21 and 3.04 for Perl may use insecure
rand() function for cryptographic functions
Description
-----------
Crypt::CBC versions between 1.21 and 3.04 for Perl may use the rand()
function as the default source of entropy, which is not
cryptographically secure, for cryptographic functions.
This issue affects operating systems where "/dev/urandom'" is
unavailable. In that case, Crypt::CBC will fallback to use the
insecure rand() function.
Problem types
-------------
CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator
(PRNG)
References
----------
https://perldoc.perl.org/functions/rand
https://metacpan.org/dist/Crypt-CBC/source/lib/Crypt/CBC.pm#L777
https://security.metacpan.org/docs/guides/random-data-for-security.html
Credits
-------
Robert Rothenberg (RRWO), finder
========================================================================
CVE-2006-0898 MITRE Corporation
========================================================================
-------------------------------------------------------------------------------
Title: Crypt::CBC ciphertext weakness when using certain block algorithms
CVE ID: CVE-2006-0898
Severity: High
Versions: All versions <= 2.16.
Date: 16 February 2006
-------------------------------------------------------------------------------
Synopsis
--------
The Perl Crypt::CBC module versions through 2.16 produce weak
ciphertext when used with block encryption algorithms with blocksize >
8 bytes.
Background
----------
Crypt::CBC implements the Cipher Block Chaining Mode (CBC) [1]. CBC
allows block ciphers (which encrypt and decrypt chunks of data of a
fixed block length) to act as though they are stream ciphers capable
of encrypting and decrypting arbitrary length streams. It does this by
randomly generating an initialization vector (IV) the same length as
the cipher's block size. This IV is logically XORed with the first
block of plaintext prior to encryption. The block is encrypted, and
the result is used as the IV applied to the next block of plaintext.
This process is repeated for each block of plaintext.
In order for ciphertext encrypted by Crypt::CBC to be decrypted, the
receiver must know both the key used to encrypt the data stream and
the IV that was chosen. Because the IV is not secret, it can safely be
appended to the encrypted message. The key, of course, is kept in a
safe place and transmitted to the recipient by some secure means.
Crypt::CBC can generate two types of headers for transmitting the
IV. The older, deprecated, header type is known as the "RandomIV"
header, and consists of the 8 byte string "RandomIV" followed by 8
bytes of IV data. This is the default header generated by Crypt::CBC
versions through 2.16. The newer, recommended, type of header is known
as the "Salted" header and consists of the 8 byte string "Salted__"
followed by an 8 byte salt value. The salt value is used to rederive
both the encryption key and the IV from a long passphrase provided by
the user. The Salted header was introduced in version 2.13 and is
compatible with the CBC header generated by OpenSSL [2].
Description
-----------
The RandomIV style header assumes that the IV will be exactly 8 bytes
in length. However, the IV must be the same length as the underlying
cipher's block size, and so this assumption is not correct when using
ciphers whose block size is greater than 8 bytes. Of the ciphers
commonly available to Perl developers, only the Rijndael algorithm,
which uses a 16 byte block size is the primary cipher affected by this
issue. Rijndael is the cipher that underlies the AES encryption
standard.
Impact
------
Ciphertext encrypted with Crypt::CBC using the legacy RandomIV header
and the Rijndael cipher is not secure. The latter 8 bytes of each
block are chained using a constant effective IV of null, meaning that
the ciphertext will be prone to differential cryptanalysis,
particularly if the same key was used to generate multiple encrypted
messages. Other >8-byte cipher algorithms will be similarly affected.
The difficulty of breaking data encrypted using this flawed algorithm
is unknown, but it should be assumed that all information encrypted in
this way has been, or could someday be, compromised.
Exploits
--------
There are no active exploits known at this time.
Workaround
----------
If using Crypt::CBC versions 2.16 and lower, pass the -salt=>1 option
to Crypt::CBC->new(). This will generate and process IVs correctly for
ciphers of all length.
Resolution
----------
Upgrade to Crypt::CBC version 2.17 or higher. This module makes the
Salted header the default behavior and refuses to encrypt or decrypt
with non-8 byte block size ciphers when in legacy RandomIV mode.
In order to decrypt ciphertext previously encrypted by pre-2.17
versions of the software with Rijndael and other >8-byte algorithms,
Crypt::CBC provides an -insecure_legacy_decrypt option that will allow
such ciphertext to be decrypted. The default is to refuse to decrypt
such data.
The most recent version of Crypt::CBC can be downloaded from the
Comprehensive Perl Archive Network (CPAN; http://www.cpan.org).
Contact
-------
For further information about this issue, please contact the author of
Crypt::CBC, Lincoln Stein <lstein@cshl.edu>.
Acknowledgements
----------------
The author gratefully acknowledges the contribution of Ben
Laurie<ben@algroup.co.uk>, who correctly identified the issue and
suggested the resolution.
References
----------
[1] http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
[2] http://www.openssl.org/
|
