3 ms·

The original version is not only bug prone. In some scenarios, both versions have a potential vulnerability. Can you spot it? In a scenario where users can acc

by pczarn 11y ago

The original version is not only bug prone. In some scenarios, both versions have a potential vulnerability. Can you spot it? In a scenario where users can access elements of a joint array of requested size without limitations, they can access memory outside the array. Memory block's total requested size may overflow size_t. Fortunately, overflow prevention is easy to add to the generic version.

Galanwe 11y ago
> both versions have a potential vulnerability. Can you spot it? What the hell are you talking about? It's a game. > In a scenario where users can access elements of a joint array of requested size without limitations, they can access memory outside the array Welcome to modern computing! A process can access any part of its mapped address space without limitation. Joke aside, are you suggesting a process should hide memory from itself? Forget it, I can't even make sense out of your comment. > Memory block's total requested size may overflow size_t Are you serious? Then please suggest a fix for C, C++, Java, and whatsnot, because nothing will prevent you in pretty much any language to ask for more memory than you can handle. This is not a _bug_, it's just expecting the programmer not to fuck around.
- jsnell 11y ago
  Example case of where it matters would be modding. There's an expectation that installing things like new textures and new models is safe. Likewise for making changes using a game's internal scripting system. If these external resources aren't properly validated, they allow a apparently safe mod to execute arbitrary code. Doesn't matter that it's a game, it's bad either way.
- pczarn 11y ago
  I'm not talking about game rendering, but multiplayer games and game servers might be affected. I mean, the requested size must come from an external source. Here's an example with a better description: https://www.verisign.com/en_US/security-services/security-intelligence/vulnerability-reports/articles/index.xhtml?id=814 https://www.verisign.com/en_US/security-services/security-in... >(...) could allow an attacker to execute arbitrary code with the privileges of the current user. >The vulnerability occurs when reading the header of the Pack200 compressed Jar file during decompression. To calculate the size of a heap buffer, the code multiplies and adds several 32-bit integers. The bounds of these values are not checked, and the arithmetic operations can overflow. This results in an undersized buffer being allocated, which leads to a heap-based buffer overflow. I remember there was a similar bug in some other decompression library.

by pczarn 11y ago

Galanwe 11y ago

> both versions have a potential vulnerability. Can you spot it? What the hell are you talking about? It's a game. > In a scenario where users can access elements of a joint array of requested size without limitations, they can access memory outside the array Welcome to modern computing! A process can access any part of its mapped address space without limitation. Joke aside, are you suggesting a process should hide memory from itself? Forget it, I can't even make sense out of your comment. > Memory block's total requested size may overflow size_t Are you serious? Then please suggest a fix for C, C++, Java, and whatsnot, because nothing will prevent you in pretty much any language to ask for more memory than you can handle. This is not a _bug_, it's just expecting the programmer not to fuck around.

jsnell 11y ago
Example case of where it matters would be modding. There's an expectation that installing things like new textures and new models is safe. Likewise for making changes using a game's internal scripting system. If these external resources aren't properly validated, they allow a apparently safe mod to execute arbitrary code. Doesn't matter that it's a game, it's bad either way.
pczarn 11y ago
I'm not talking about game rendering, but multiplayer games and game servers might be affected. I mean, the requested size must come from an external source. Here's an example with a better description: https://www.verisign.com/en_US/security-services/security-intelligence/vulnerability-reports/articles/index.xhtml?id=814 https://www.verisign.com/en_US/security-services/security-in... >(...) could allow an attacker to execute arbitrary code with the privileges of the current user. >The vulnerability occurs when reading the header of the Pack200 compressed Jar file during decompression. To calculate the size of a heap buffer, the code multiplies and adds several 32-bit integers. The bounds of these values are not checked, and the arithmetic operations can overflow. This results in an undersized buffer being allocated, which leads to a heap-based buffer overflow. I remember there was a similar bug in some other decompression library.