obscure printf(3) format string features, used in fewer places in your codebase than you have fingers on your right hand
I just did a quick grep of /usr/src and counted 17 places where %n was used in a format string -- fairly equally split between printf and scanf. I don't know what sort of mutant you think I am, but I don't have that many fingers on my right hand.
And that's not even counting all of the 3rd party code which gets run on FreeBSD (including the 18000+ programs in the ports tree) which make the perfectly reasonable assumption that FreeBSD's printf(3) conforms to POSIX requirements.
you tried to remove Hyperthreading from FreeBSD
No, I didn't. I turned it off by default. There's a big difference.
Are you sure you're still speaking as FreeBSD Security Officer? I may quote you on some of this in the future.
Here's a quote for you: As FreeBSD Security Officer, I do not believe that POSIX-mandated features should be removed in an attempt to make foot-shooting harder. The printf and scanf family of functions are dangerous, and should NEVER be called with a format string provided by a potential attacker or constructed from data provided by a potential attacker.
After I worked (very briefly with the project, more extensively out of it) on FreeBSD, I played a minor part in the OpenBSD audit, back when it was mostly Theo and bitblt. You're the FreeBSD Security Officer, you should know all about that.
OpenBSD made vast, sweeping changes to their code to minimize and mitigate security problems. Have you read privsep SSH?
How much third-party code links to your unsafe libc? How could you know? You think it's more sound to rely on every undereducated third-party developer to make the right choices about using your libraries, than to simply scrub out the seventeen (17. really.) places in your own code that use an apocryphal and dangerous printf feature, so you can eliminate it?
You're way out of step with the rest of your peer group, which appears to have learned not to trust random developers to use C libraries safely.
I love that argument. "Bad programming? Use good programming. Not our fault." By that logic, there's no security benefit to writing web apps in Python over C.
simply scrub out the seventeen (17. really.) places in your own code that use an apocryphal and dangerous printf feature, so you can eliminate it?
Go back and read what I wrote. There are 17 places in the FreeBSD base system where %n is used in a format string. I have no clue how many times it's used in code in the FreeBSD ports tree, or in 3rd party code which isn't in the ports tree -- and I'm not going to go and break lots of perfectly good code just because someone might shoot themself in the foot.
Yes, you've definitely made it clear that you don't think it's your problem. Maybe if you just turn "%n" off by default. That's not the same thing as breaking the code, is it?
Anyways, this is a tangent. It's amusing that you can stick up (in some sense) for clientside Javascript security, which is at least 0.0001% more secure than plaintext, but at the same time conduct protected arguments in the mailing lists about why CPU features should be turned off, lest someone ever figure out a way to make an attack you helped research become feasible.
I just did a quick grep of /usr/src and counted 17 places where %n was used in a format string -- fairly equally split between printf and scanf. I don't know what sort of mutant you think I am, but I don't have that many fingers on my right hand.
And that's not even counting all of the 3rd party code which gets run on FreeBSD (including the 18000+ programs in the ports tree) which make the perfectly reasonable assumption that FreeBSD's printf(3) conforms to POSIX requirements.
you tried to remove Hyperthreading from FreeBSD
No, I didn't. I turned it off by default. There's a big difference.
Are you sure you're still speaking as FreeBSD Security Officer? I may quote you on some of this in the future.
Here's a quote for you: As FreeBSD Security Officer, I do not believe that POSIX-mandated features should be removed in an attempt to make foot-shooting harder. The printf and scanf family of functions are dangerous, and should NEVER be called with a format string provided by a potential attacker or constructed from data provided by a potential attacker.