[RFC] libio FILE/vtable hardening ideas against FSOP-style attacks

[류대호]

Hello glibc developers, My name is Daeho Ryu, and I am an undergraduate student in the Department of Cyber Defense at Korea University. I have recently been studying user-space exploitation and glibc internals, especially FSOP-related techniques. As part of my capstone project, I built a small prototype to test a few libio hardening ideas. This is not a production-ready patch submission. Before trying to prepare a cleaner patch, I wanted to ask whether these ideas make sense from glibc's point of view. The prototype is based on glibc 2.43, and it currently tests three things. First, I added validation to the wide vtable path. Some FSOP techniques, such as House of Apple 2 and House of Apple 3, use wide-oriented FILE fields as attack targets. In my prototype, _IO_WIDE_JUMPS_FUNC passes the wide vtable through IO_validate_vtable , similar to the normal FILE vtable path. Second, I tested stricter vtable checks. The current validation checks whether the vtable pointer is inside the expected vtable section range. I also tried checking whether the pointer matches the exact start address of known libio vtables. For now, I tested this idea on the _IO_OVERFLOW path first. Third, I tried a small registry-based integrity check for important FILE metadata. Since FILE objects are writable data structures, the prototype records selected trusted values during normal libio operations with pointer guards and compares them again before sensitive paths. In my local tests, the wide-vtable validation showed less than 1% runtime overhead. The stricter vtable-start check and registry-based check showed runtime differences within about 5%. These are only preliminary measurements, so I do not want to make a strong performance claim yet. I would appreciate any feedback on these questions: Does validating the wide vtable path with IO_validate_vtable seem like a reasonable hardening direction? Is exact vtable start-address checking too strict for glibc, or could it be useful in some limited paths? Is a FILE metadata registry fundamentally incompatible with libio, or is it worth exploring as an optional hardening idea? If useful, I can share a short design note, the current prototype repository, or a smaller patch focused only on the wide-vtable validation change. Thank you for your time!!!! Best regards, Daeho Ryu Department of Cyber Defense Korea University GitHub: daepo666
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260622/2fc0b7b3/attachment-0001.htm>