3 ms·
This only protects you against unintentional use-after-free. If a use-after-free of struct ws is a thing you're worried about an attacker intentionally causing,
by geofft 5y ago
This only protects you against unintentional use-after-free. If a use-after-free of struct ws is a thing you're worried about an attacker intentionally causing, in order for this to be useful, the attacker needs to control one of those four char * pointers and point them somewhere useful. Typically they'd do that by inducing the program to re-allocating the freed memory with a buffer under their control (like input from the network) and then filling it in with specific bytes.
If they can do that, they can very easily fill in the magic numbers too. It's even easier than pointers because it doesn't require inferring information about the running program - the magic number is the same across all instances of Varnish and right there in the source.
"Heap spray" attacks are a generalization of this where the attacker doesn't have precise enough control about what happens between the unwanted free and the reuse, but they can allocate a very large buffer (e.g., send a lot of data in from the network, or open a lot of connections) and put their data in that way. This approach would be basically perfect for defeating the "magic number" approach.
(The blog post itself has a discussion of a number of more advanced variants on the "magic number" approach - see the mention of "tagging pointers with a small number of bits that are checked against object metadata on access".)
- tjalfi 5y agoThe Stratus recommendations for structure marking would be a bit harder to defeat. Here's an excerpt from an old Stratus presentation[0] on writing robust software. Add TYPE, SIZE, VERSION, and OWNER to data structure TYPE: Unique number for each different structure SIZE: in bytes VERSION: Changed whenever structure declaration changes OWNER: Unique ID of owner, must be independent of structure contents; can be UID, least significant bits of clock, etc. [0] https://web.archive.org/web/20170303065858/http://ftp.stratus.com/vos/doc/papers/RobustProgramming.ps https://web.archive.org/web/20170303065858/http://ftp.stratu...
- nyc_pizzadev 5y ago> they can very easily fill in the magic numbers too Right, recreating the magic does side step this defense. The context for software security these days is defense in depth and not something like “total defense” anymore. In this case, the use of magics is more of a dev testing mechanism than a runtime protect, although it does provide great runtime protection. What this means is if you use magics with proper testing and load testing, errors should surface before you release.