코드 품질이 낮으면 예측할 수 없는 동작이 발생합니다. 사용자 입장에서는 사용 편의성이 떨어지는 것으로 나타나는 경우가 많습니다. 공격자에게는 예상치 못한 방법으로 시스템에 부담을 줄 수 있는 기회가 됩니다.
FLAG_MUTABLE로 설정된 PendingIntent가 감지되었습니다. FLAG_MUTABLE 플래그 값으로 생성된 PendingIntent는 지정되지 않은 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() 호출이 원래의 할당에 대한 크기 조절이 실패하면 할당된 메모리 블록을 누출합니다.
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이 될 수 있는 포인터를 역참조할 경우 발생합니다. 검사 후 역참조(dereference-after-check) 오류는 프로그램이 null인지 여부를 명시적으로 검사하지만, null인 것으로 알려진 포인터를 역참조할 때 발생합니다. 이 유형의 오류는 철자 오류 또는 프로그래머의 실수로 발생합니다. 저장 후 역참조(dereference-after-store) 오류는 프로그램이 명시적으로 포인터를 null로 설정하고 이를 나중에 역참조할 경우에 발생합니다. 이 오류는 프로그래머가 선언된 상태의 변수를 null로 초기화하여 발생하는 경우가 많습니다.ptr이 NULL이 아닌 것으로 가정합니다. 이 가정은 프로그래머가 포인터를 역참조하면 명시적인 것이 됩니다. 프로그래머가 NULL에 대해 ptr을 검사하면 이 가정이 반박됩니다. if문에서 검사할 때 ptr이 NULL이 되면 역참조될 때도 NULL이 되어 조각화 오류가 발생할 수 있습니다.예제 2: 다음 코드에서 프로그래머는 변수
ptr->field = val;
...
if (ptr != NULL) {
...
}
ptr이 NULL임을 확인한 다음 실수로 역참조합니다. if문에서 검사할 때 ptr이 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를 두 번째 매개 변수로 전달하는데, 이 값은 사용자가 빈 암호로 연결할 경우의 허용 여부를 결정합니다. 이 매개 변수에 false를 전달하는 것은 빈 암호를 허용할 수 없다는 뜻입니다.
...
SCP = new SqlClientPermission(pstate, false);
...
PermissionState 개체가 두 번째 매개 변수에 전달되는 값을 대체하기 때문에 구성자는 데이터베이스 연결에 빈 암호를 허용합니다. 이는 두 번째 인수에 위배됩니다. 빈 암호를 허용하지 않으려면 프로그램이 PermissionState.None을 구성자의 첫 번째 매개 변수에 전달해야 합니다. 이 기능상의 모호함 때문에 두 개의 매개 변수를 사용하는 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() 함수를 사용하면 보안상 문제가 될 수 있습니다. 이 함수가 두 번째 매개 변수로 전달되는 버퍼를 overflow할 수 있기 때문입니다. 이 같은 취약성 때문에 getpw()는 getpwuid()로 대체되었습니다. getpwuid()는 getpw()와 같은 조회 작업을 수행하지만 정적으로 할당되는 구조에 대한 포인터를 반환하여 위험을 완화합니다.
...
String name = new String(nameBytes, highByte);
...
nameBytes로 표시되는 문자열을 인코딩하는 데 사용되는 charset에 따라 바이트를 문자로 올바르게 변환하지 못할 수 있습니다. 문자열을 인코딩하는 데 사용되는 charset의 진화로 인해 이 생성자는 더 이상 사용되지 않으며 변환을 위해 바이트를 인코딩하는 데 사용되는 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() { }
}