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
|
ESAPI for Java - 2.1.0 Release Notes
1) Fixed security issue #306, a vulnerability discovered by Phillipe Arteau.
This fix necessitated removing the deprecated encrypt() and decrupt() methods
that were intended to provide backward compatibility with ESAPI 1.4.
As it turns out, there was no way to fix this bug without a major rewrite
unless these methods were removed. However, as these two methods have been
deprecated more than 2 years ago and they are known to be insecure
(they are vulnerable to padding oracle attacks), the ESAPI team has
decided to remove them in accordance to their support policy.
See comments for issue #306 for further details, as well as additional
safety precautions that you may wish to take in the unlikely, but possible
event that this vulnerability resulted in an actual security breach.
Finally, since the removal of these methods constitute an interface change
(to the Encryptor interface), this is considered a minor release (2.1)
rather than simply a patch release (2.0.2).
Please note that there are further updates planned to further strengthen
the MAC that ESAPI crypt uses. However, because they will require some
design changes, they may not be out for another month. Note that these
fixes do not correct any *known* vulnerabilities, but will address
some potential weaknesses in what is not included in the MAC (such as
the crypto version).
2) Other Google Issues fixed: 257, 271, and 292 are all fixed in this release.
3) Fixed Javadoc for Encoder.encryptForJavaScript(). [Revision r1879]
4) DefaultEncryptedProperties - made minor Javadoc changes.
5) The ESAPI 2.0 Encryptor.encrypt() methods now all throw an appropriate
IllegalArgumentException if any of the arguments are null. Previously,
if any of the arguments were null you would either get an AssertionError
(if you had assertions enabled) or a default NullPointerException when
assertions were disabled. While IllegalArgumentException is still an
unchecked RuntimeException, note that if you were previously catching
NullPointerExceptions for these cases, you may need to change your code.
6) The public constructor, CiphertextSerializer(CipherText ct), was changed
to explicitly check that the parameter is not null. Previously it had
checked with assertions which might later result in a NullPointerException
being thrown if assertions were disabled. Now if the parameter is null,
an appropriate IllegalArgumentException is thrown. This should not really
affect existing code (unless you are experimenting implementing your own
crypto) since user code should not really be using CiperTextSerializer
directly.
7) Some of the setter methods in KeyDerivationFunction were changed to explicitly
check for invalid arguments and throw an IllegalArgumentException rather than
checking these parameters via assertions. This should not affect general
user code as most would not be calling the KeyDerivationFunction class
directly.
8) Other miscellaneous minor code clean-up, mostly to remove compiler warnings.
NOTE: A follow-up patch release is scheduled within the next few months to
address some questionable design decisions regarding what data in
the serialized ciphertext should be authenticated via the MAC. For
instance, presently only the IV+ciphertext is MAC'd (as would be the
equivalent case of when you would use an authenticated combined cipher
mode such as GCM or CCM). A deeper analysis of the design is required
based on findings in Google Issue # 306. I will periodically try
to keep the ESAPI mailing lists updated with the progress so watch
there for emerging details and anticipated schedule.
-Kevin W. Wall <kevin.w.wall@gmail.com>, 2013-08-30
|
