4 ms·

The author argues against crashing on integer overflow by drawing an example from a totally different domain for which Swift is not at all intended. Integer ov

by zvrba 12y ago

The author argues against crashing on integer overflow by drawing an example from a totally different domain for which Swift is not at all intended. Integer overflow has been a source of numerous exploits, and I'd prefer the software on my desktop machine / phone / tablet to crash instead of giving unlimited access to the intruder. The story changes radically if we start talking about mission critical systems, like car control.

mpweiher 12y ago
Looking at https://www.owasp.org/index.php/Integer_overflow https://www.owasp.org/index.php/Integer_overflow the consequences of integer overflow by itself either crashes/infinite loops. Crashing on overflow is not an improvement in these cases. To get into exploitable access, you need buffer overflows, which can and should be protected against separately. Once you protect against buffer overflows, crashing on integer overflows gets you exactly nothing. (Might be OK as an optional, assert-like debugging tool).
- zvrba 12y ago
  > To get into exploitable access, you need buffer overflows, which can and should be protected against separately. Or you can use overflow to make the program to allocate too small buffer thus obtaining the buffer overflow you need to proceed further.
  - mpweiher 12y ago
    You're not making any sense: I already wrote "protect against buffer overflow instead of integer overflow" and your response is "buffer overflow".
    - zvrba 12y ago
      Integer overflow can be a causal cause of buffer overflow. Like this for example: read(fd, &header, sizeof(header)); int total_len = header.data_len + header.code_len; char *data = malloc(total_len); read(fd, data, total_len); Now, the attacker crafts the file and.. there's your buffer overflow which is a direct consequence of undetected integer overflow [i.e., the program being allowed to proceed].
      - mpweiher 12y ago
        Once again: if you protect against buffer overflow, an integer overflow that might lead to buffer overflow doesn't matter. The C example doesn't matter because C has neither.

by zvrba 12y ago

mpweiher 12y ago

Looking at https://www.owasp.org/index.php/Integer_overflow https://www.owasp.org/index.php/Integer_overflow the consequences of integer overflow by itself either crashes/infinite loops. Crashing on overflow is not an improvement in these cases. To get into exploitable access, you need buffer overflows, which can and should be protected against separately. Once you protect against buffer overflows, crashing on integer overflows gets you exactly nothing. (Might be OK as an optional, assert-like debugging tool).

zvrba 12y ago
> To get into exploitable access, you need buffer overflows, which can and should be protected against separately. Or you can use overflow to make the program to allocate too small buffer thus obtaining the buffer overflow you need to proceed further.
- mpweiher 12y ago
  You're not making any sense: I already wrote "protect against buffer overflow instead of integer overflow" and your response is "buffer overflow".
  - zvrba 12y ago
    Integer overflow can be a causal cause of buffer overflow. Like this for example: read(fd, &header, sizeof(header)); int total_len = header.data_len + header.code_len; char *data = malloc(total_len); read(fd, data, total_len); Now, the attacker crafts the file and.. there's your buffer overflow which is a direct consequence of undetected integer overflow [i.e., the program being allowed to proceed].
    - mpweiher 12y ago
      Once again: if you protect against buffer overflow, an integer overflow that might lead to buffer overflow doesn't matter. The C example doesn't matter because C has neither.