Hi Ingo, At 2026-02-06T14:46:55+0100, Ingo Schwarze wrote: > G. Branden Robinson wrote on Thu, Feb 05, 2026 at 12:34:16AM -0600: > > Can you name a security problem arising from groff's use of a > > standard C library facility that OpenBSD's libc implementation would > > prevent or mitigate, but which gnulib replaces and thereby > > re-exposes? > > I already named an example, maybe it was overlooked among the > significant number of mails: > > * Support for printf(3) %n was removed from OpenBSD libc > for security reasons. > * GNUlib printf(3) supports %n. > * One of the reasons why the groff build system replaces native > OpenBSD printf(3) - and many other functions - by GNUlib printf(3) > is that GNUlib printf(3) supports %n.
I do have a vague memory of you mentioning this, but not recently. > As far as i know, groff does not (intentionally) use %n. Indeed not. From the groff 1.23.0 ChangeLog: 2021-08-15 G. Branden Robinson <[email protected]> Resolve compiler warnings relating to format string security and ISO C++98 conformance. * src/preproc/eqn/delim.cpp (define_extensible_string): * src/preproc/pic/pic.ypp (do_sprintf): Use #pragma to silence GCC "format-nonliteral" warning and explain why our usage is safe in a comment. * src/preproc/preconv/preconv.cpp (detect_file_encoding): Use `l` modifier to `%u` `fprintf()` conversion instead of `z`, and cast return values of `size_t` to unsigned long; "ISO C++98 does not support the ‘z’ gnu_printf length modifier" (it doesn't support `ll` either). N.B. this is debugging output only. * src/roff/groff/groff.cpp (synopsis): * src/roff/troff/input.cpp (usage): Repeat variadic argument for `%s` conversion in `fprintf()` call because "ISO C++98 does not support %n$ operand number formats". ... I see no other _relevant_ matches in the groff source tree for `%n`, though as I'm sure you'd (rightly) point out, that's no defense if we commit the grave mistake of permitting the input to construct format strings _for_ us, and you're correct that OpenBSD's nonstandard printf(3) mitigates such a weakness if it exists. https://cwe.mitre.org/data/definitions/134.html > That makes the choice to insist on having it quite strange. I _don't_ insist. printf(3)'s `n` conversion specifier comes with gnulib and conforms to the POSIX standard. https://pubs.opengroup.org/onlinepubs/9799919799/functions/printf.html If OpenBSD wants to make its printf(3) the standard, it knows who to talk to. > On the other hand, "we don't use it, so having it available in the > implementation poses no risk" is a weak argument. Not necessarily. That depends on how easy it is to attack groff's executable programs so as to gain control of a format strings it uses _and_ its parameter list. Compare that to how easy it is to inject object code that does what `printf("%n", &foo)` would have achieved, or (more likely, I suspect) some more direct means of overwriting memory with a small integer. > Defense in depth means that you get the best level of security when > you do *both*: *neither* use the dangerous feature *nor* provide it in > the implementation - because that means not even a bug can trigger its > accidental use. It's a good principle. But few principles should be adhered to slavishly, and I suggest that the vituperation with which express of groff's propensity to crash during compilation--but only on OpenBSD and when crudely attempting to defeat linkage with gnulib, factors you never disclose to your readers without prompting--indicates how tightly you're fastening an iron collar around your own neck. Again, if someone can tell me how to (easily) set up the moral equivalent of a `--without-gnulib` option to groff's "configure" script, I'm inclined to embrace it. I would have "configure.ac" disclose this fact in the configuration summary, and its exercise could influence the level of support I'm willing to extend to such configurations. That said, I have no reason to suspect any particular problems apart from people discovering dismaying deficiencies in their systems' C libraries, blaming groff for those deficiencies, getting pissed off, and writing screeds on the Web about how they're moving their bookmarks to Markdown/ Heirloom/Typst/TeX/whatever. See, e.g., "etresoft" at <https://discussions.apple.com/thread/\ 256113690?sortBy=rank>. So be careful out there, folks--like a slave collar, a black turtleneck can constrict blood flow to the brain. Regards, Branden
signature.asc
Description: PGP signature
