コードの質が低いと、予測できない動作につながります。ユーザーの視点には、それがしばしば使い勝手の悪さとなって現れます。攻撃者にとっては、予期せぬ方法でシステムにストレスを与える機会となります。
FLAG_MUTABLE に設定された PendingIntent が検出されています。フラグ値 FLAG_MUTABLE を使用して作成されたペンディング インテントでは、未指定の Intent フィールドにダウンストリームを設定されやすく、その結果、Intent のキャパシティが変更され、システムが攻撃にさらされやすくなります。PendingIntent の基盤となる Intent の変更を、作成後に許可すると、システムが攻撃にさらされやすくなります。これは主に、基盤となる Intent の全体的な機能に依存します。ほとんどの場合、PendingIntent フラグを FLAG_IMMUTABLE に設定することが、潜在的な問題を防ぐためのベスト プラクティスです。FLAG_MUTABLE を使用して作成された PendingIntent が含まれています。
...
val intent_flag_mut = Intent(Intent.ACTION_GTALK_SERVICE_DISCONNECTED, Uri.EMPTY, this, DownloadService::class.java)
val flag_mut = PendingIntent.FLAG_MUTABLE
val pi_flagmutable = PendingIntent.getService(
this,
0,
intent_flag_mut,
flag_mut
)
...
read() のコールが予想バイト数を戻せない場合に、割り当てられているメモリのブロックが漏洩します。
char* getBlock(int fd) {
char* buf = (char*) malloc(BLOCK_SIZE);
if (!buf) {
return NULL;
}
if (read(fd, buf, BLOCK_SIZE) != BLOCK_SIZE) {
return NULL;
}
return buf;
}
CALL "CBL_ALLOC_MEM"
USING mem-pointer
BY VALUE mem-size
BY VALUE flags
RETURNING status-code
END-CALL
IF status-code NOT = 0
DISPLAY "Error!"
GOBACK
ELSE
SET ADDRESS OF mem TO mem-pointer
END-IF
PERFORM write-data
IF ws-status-code NOT = 0
DISPLAY "Error!"
GOBACK
ELSE
DISPLAY "Success!"
END-IF
CALL "CBL_FREE_MEM"
USING BY VALUE mem-pointer
RETURNING status-code
END-CALL
GOBACK
.
dealloc() メソッドでメモリの解放に失敗します。init() メソッドでメモリを割り当てますが、deallocate() メソッドでメモリの解放に失敗するため、Memory Leak が発生します。
- (void)init
{
myVar = [NSString alloc] init];
...
}
- (void)dealloc
{
[otherVar release];
}
realloc() のコールが元のメモリ割り当てのサイズ変更に失敗した場合に、次の C 関数は割り当てられているメモリブロックをリークしています。
char* getBlocks(int fd) {
int amt;
int request = BLOCK_SIZE;
char* buf = (char*) malloc(BLOCK_SIZE + 1);
if (!buf) {
goto ERR;
}
amt = read(fd, buf, request);
while ((amt % BLOCK_SIZE) != 0) {
if (amt < request) {
goto ERR;
}
request = request + BLOCK_SIZE;
buf = realloc(buf, request);
if (!buf) {
goto ERR;
}
amt = read(fd, buf, request);
}
return buf;
ERR:
if (buf) {
free(buf);
}
return NULL;
}
realloc() の呼び出しが元の割り当てのサイズ変更に失敗した場合に、割り当て済みメモリのブロックをリークします。
CALL "malloc" USING
BY VALUE mem-size
RETURNING mem-pointer
END-CALL
ADD 1000 TO mem-size
CALL "realloc" USING
BY VALUE mem-pointer
BY VALUE mem-size
RETURNING mem-pointer
END-CALL
IF mem-pointer <> null
CALL "free" USING
BY VALUE mem-pointer
END-CALL
END-IF
NullException を引き起こします。cmd」という名前の定義されたプロパティがあると前提しています。攻撃者がプログラムの環境を制御して「cmd」を未定義にできる場合、プログラムが Trim() メソッドのコールを試みると NULL ポインタ例外が発生します。
string cmd = null;
...
cmd = Environment.GetEnvironmentVariable("cmd");
cmd = cmd.Trim();
null であるかを確認する前に、null の可能性があるポインタを間接参照する場合です。チェック後間接参照のエラーが発生するのは、プログラムが null に対して明示的チェックを実行したにも関わらず、null であることが判明しているポインタを間接参照した場合です。この種のエラーの多くは、タイプミスかプログラマの不注意が原因です。格納後間接参照のエラーは、プログラムが明示的にポインタを null に設定し、後でそのポインタを間接参照した場合に発生します。このエラーは通常、変数の宣言時にプログラマがその変数を null に初期化したことが原因で発生します。ptr は NULL ではないと仮定してします。この仮定は、プログラマがポインタを間接参照したときに明らかになります。その後プログラマが ptr と NULL を比較したときに、この仮定は成り立たなくなります。ptr が if ステートメントでチェックされたときに NULL であるとすれば、間接参照されたときにも NULL である可能性があり、これがセグメンテーション違反の原因となる場合があります。例 2: 次のコードでは、プログラマは変数
ptr->field = val;
...
if (ptr != NULL) {
...
}
ptr が NULL であることを確認してから、続いてそれを誤って間接参照しています。ptr が if ステートメントでチェックされたときに NULL になっていると、null Dereference が発生し、これがセグメンテーション違反の原因となります。例 3: 次のコードでは、プログラマが文字列
if (ptr == null) {
ptr->field = val;
...
}
'\0' (実際は 0) または NULL を忘れたため、NULL ポインタを間接参照し、セグメンテーション違反を引き起こしています。例 4: 次のコードでは、プログラマは明示的に変数
if (ptr == '\0') {
*ptr = val;
...
}
ptr を NULL に設定しています。続いて、オブジェクトの null 値をチェックする前に ptr を間接参照しています。
*ptr = NULL;
...
ptr->field = val;
...
}
NullPointerException を引き起こします。cmd」という名前の定義されたプロパティがあると前提しています。攻撃者がプログラムの環境を制御して「cmd」を未定義にできる場合、プログラムが trim() メソッドのコールを試みると NULL ポインタ例外が発生します。
String val = null;
...
cmd = System.getProperty("cmd");
if (cmd)
val = util.translateCommand(cmd);
...
cmd = val.trim();
SqlClientPermission オブジェクトを構成します。この例のプログラムは、ユーザーがパスワードを空欄にして接続できるかどうかを制御するコンストラクタに false を 2 番目のパラメーターとして渡しています。このパスワードに False を渡すと、空欄のパスワードは許容されなくなります。
...
SCP = new SqlClientPermission(pstate, false);
...
PermissionState オブジェクトが 2 番目のパラメーターとして渡されるあらゆる値より優先されるため、コンストラクタはパスワードを空欄にしてデータベースに接続することを許容し、2 番目の引数に反する事態が発生します。空欄のパスワードを拒否するには、プログラムがコンストラクタの最初のパラメーターに PermissionState.None を渡すようにします。誤った解釈を生む危険がなく同じ情報を伝達できる単一パラメーターのバージョンに比べた場合、このような機能的なあいまいさが存在しているため、パラメーターを 2 つ取るバージョンの SqlClientPermission コンストラクタの仕様は現在の状況には適当でないものとなっています。 getpw() を使用して平文のパスワードが、暗号化されたユーザーパスワードと一致するかどうかを検証しています。パスワードが有効であれば、関数は result を 1 に、それ以外の場合は 0 にします。
...
getpw(uid, pwdline);
for (i=0; i<3; i++){
cryptpw=strtok(pwdline, ":");
pwdline=0;
}
result = strcmp(crypt(plainpw,cryptpw), cryptpw) == 0;
...
getpw() 関数が問題になることがあります。これは、2 つ目のパラメーターに渡されたバッファがオーバーフローするためです。この脆弱性のために、getpw() は、getpw() と同じルックアップを実行しても、静的に割り当てられた構造体にポインタを戻す (リスクを緩和するため) getpwuid() に置き換えられてきました。
...
String name = new String(nameBytes, highByte);
...
nameBytes で表される文字列のエンコードにどの文字セットが使用されているかによって、コンストラクターがバイトを文字に正しく変換できない可能性があります。文字列のエンコードに使用される文字セットの進化により、このコンストラクターは非推奨となり、パラメーターの 1 つとして、変換のためにバイトをエンコードするために使用される、charset という名前のパラメーターを受け入れるコンストラクターに置き換えられました。Digest::HMAC stdlib を使用しています。これはリリース内に誤って含まれたために、ドキュメントで明示的に使用を禁止しています。
require 'digest/hmac'
hmac = Digest::HMAC.new("foo", Digest::RMD160)
...
hmac.update(buf)
...
Digest::HMAC クラスは、リリース内に誤って含まれたため、追加直後に廃止されています。実験的で適切にテストされていないコードであり、期待どおりに動作しない可能性があるため、特に HMAC の暗号化機能に関する関係を考慮すると、この使用を避けることを強くお勧めします。block.blockhash() を使用して現在のブロックのハッシュを取得します。これは、Solidity コンパイラーのバージョン 0.5.0 以降非推奨になりました。
bytes32 blockhash = block.blockhash(0);
IsBadXXXPtr() クラスを使用すべきではない理由は多数あります。これらの関数には次のような特徴があります。IsBadWritePtr() が使用されています。
if (IsBadWritePtr(ptr, length))
{
[handle error]
}
public class Totaller {
private int total;
public int total() {
...
}
}
hardcap かを見極めるのは困難になる可能性があります。
contract Tokensale {
uint hardcap = 10000 ether;
function Tokensale() { }
function fetchCap() public constant returns(uint) {
return hardcap;
}
}
contract Presale is Tokensale {
uint hardcap = 1000 ether;
function Presale() Tokensale() { }
}