...
| Code Block | ||
|---|---|---|
| ||
BigInteger msg = new BigInteger("123");
msg = msg.modPow(exp, m); // Always returns 1
// Malicious subclassing of java.math.BigInteger
class BigInteger extends java.math.BigInteger {
private int value;
public BigInteger(String str) {
super(str);
value = Integer.parseInt(str);
}
public void setValue(int value) {
this.value = value;
}
@Override public java.math.BigInteger modPow(java.math.BigInteger exponent, java.math.BigInteger m) {
this.value = ((int) (Math.pow(this.valuedoubleValue(), exponent.doubleValue()))) % m.intValue();
return this;
}
}
|
This malicious BigInteger class is clearly mutable because of the setValue() method. Furthermore, the modPow() method is subject to precision loss. (See rules "NUM00-J. Detect or prevent integer overflow," "NUM11-J. Check floating-point inputs for exceptional values," "NUM15-J. Ensure conversions of numeric types to narrower types do not result in lost or misinterpreted data," and "NUM17-J. Beware of precision loss when converting primitive integers to floating-point" for more information.) Any code that receives an object of this class and assumes that the object is immutable will have unexpected behavior. This is particularly important because the BigInteger.modPow() method has several useful cryptographic applications.
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="d9f42e8b1ef050ba-b8b90508-4cf645e9-921ba10e-f5723459397c17baf586a8dc"><ac:plain-text-body><![CDATA[ | [[API 2006 | AA. Bibliography#API 06]] | Class BigInteger | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="3569f9a7328e62ed-a168094d-4cb149f7-af07a94e-75b784c7823d397f38de91cc"><ac:plain-text-body><![CDATA[ | [[Bloch 2008 | AA. Bibliography#Bloch 08]] | Item 1: "Consider static factory methods instead of constructors" | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="43137d4b46dd803b-e754405e-4a7d449f-bc34bc06-72de7e3d1e5acd032c8ac29e"><ac:plain-text-body><![CDATA[ | [[Gong 2003 | AA. Bibliography#Gong 03]] | Chapter 6: "Enforcing Security Policy" | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="597388f1429eaf46-faf385e7-4c4249e9-ac328e96-e2467b4f0d7a946c8136faa7"><ac:plain-text-body><![CDATA[ | [[Lai 2008 | AA. Bibliography#Lai 08]] | Java Insecurity: Accounting for Subtleties That Can Compromise Code | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="5a4efb672b9f15f4-5fe50f15-4a8c4876-9d83a557-1bc1f585919b30d698e5be74"><ac:plain-text-body><![CDATA[ | [[McGraw 1999 | AA. Bibliography#McGraw 99]] | Chapter Seven Rule 3: "Make Everything Final, Unless There's a Good Reason Not To" | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="639887640746d744-e5e5aeb0-4e5f4023-ad618d90-9e04b1b5e886836f292333f8"><ac:plain-text-body><![CDATA[ | [[Ware 2008 | AA. Bibliography#Ware 08]] | ]]></ac:plain-text-body></ac:structured-macro> |
...