Mathias Payer

Canaries and other techniques that leverage volatiles do not prevent an overflow; they just try to cope with the consequences of an overflow which has happened. (This is why they're generally lumped together as "mitigation".) The canary tries to detect the case of an overflow which overwrites the return address in a stack frame. Data Execution Prevention (DEP) takes this idea a step further, it assumes that the return address has been overwritten and followed, and it restricts the areas where execution could jump. ASLR is yet another step further: it "shuffles" the areas where execution is allowed. More specifically, stack canaries work by modifying every function's prologue and epilogue regions to place and check a value on the stack respectively. As such, if a stack buffer is overwritten during a memory copy operation, the error is noticed before execution returns from the copy function. When this happens, an exception is raised, which is passed back up the exception handler hierarchy until it finally hits the OS's default exception handler. If you can overwrite an existing exception handler structure in the stack, you can make it point to your own code. This is a Structured Exception Handling (SEH) exploit, and it allows you to completely bypass the canary check. DEP and NX (what OpenBSD calls W^X) mark important structures in memory as non-executable, and force hardware-level exceptions if you try to execute those memory regions. This makes normal stack buffer…

[One of the authors here] Type++ analyzes all application code and infers which classes are ever cast. All of those classes are adapted to include type information (in the form of an RTTI field). All casts are then changed into explicit casts. As a dialect, some light changes are necessary and we evaluate the amount of code changes --- which are usually small. This gives us type safety for even large programs as evaluated. A short blog is available here: https://nebelwelt.net/blog/2025/0226-typepp.html

Somewhat related to this, printf alone in a loop is Turing-complete, by using %-directives like that. It was introduced in “Control-Flow Bending: On the Effectiveness of Control-Flow Integrity” (Carlini, et al. 2015) and the authors have implemented Brainfuck and an obfuscated tic-tac-toe with it. [0]: https://nebelwelt.net/publications/files/15SEC.pdf [1]: https://github.com/HexHive/printbf [2]: https://github.com/carlini/printf-tac-toe

It does not need the loop. It might be easier to understand by looking at something like this. [0] That printf allows for this kind of Turing complete control flow is well known [1]. [0] https://github.com/HexHive/printbf [1] http://nebelwelt.net/publications/files/15SEC.pdf

This is by the same author as the ioccc entry and also one of authors of the paper showing the turing completeness of printf http://nebelwelt.net/publications/#15SEC

Research: http://hexhive.epfl.ch/publications/files/20SEC3.pdf https://nebelwelt.net/publications/files/20SEC3.pdf (mirror) Tool will be open source. Repo is being prepped and when it is live will be available at: https://github.com/HexHive/USBFuzz

Blog post explaining the details: https://nebelwelt.net/blog/20190306-SMoTherSpectre.html Seems to be dependent on SMT.

The paper itself: https://nebelwelt.net/files/20SEC3.pdf

You and the person I replied to above are essentially correct: >Fuzzing drivers on [FreeBSD, MacOS, and Windows] is more challenging than the Linux kernel due to the lack of support infrastructure. These OSes support neither KASAN, other sanitizers, nor coverage-based collection of executions. The lack of a memory-based sanitizer means our fuzzer only discovers bugs that trigger exceptions, and misses all bugs that silently corrupt memory. Because we cannot collect coverage information, our fuzzer cannot detect seeds that trigger new inputs. (https://nebelwelt.net/files/20SEC3.pdf) The researchers employed a partial workaround for the problem, but it is pretty obvious to me that the partial workaround does not level the playing field: >To alleviate the second concern, the lack of coverage-guided optimization, we experiment with cross-pollination. To seed our dumb fuzzer, we reuse the inputs generated during our Linux kernel fuzzing campaign.