I've been following tedu's blog and one of the interesting topics that came up in OpenBSD was W^X memory, which apparently didn't get along well with JIT compilers, so they devised a new memory protection scheme called now-or-never execution.
Outside of OpenBSD land, do you see either of these two (W^X, nonexec) being used in a future version of Adobe Flash Player? (and/or in Chrome/Firefox?)
I uninstalled Flash on my work and home Macs the other day. I must say, it cuts way down on any videos I watch. Pretty much everything except youtube is Flash. Oh well. Not reinstalling it, though. Too much risk.
Greats side effect: no more autoplay videos on random news sites.
I either have headphones in or volume muted, on all computers at all times. If I'm about to unplug headphones I quick mute first. No problems with unwanted audio.
Flash is theoretically a "safe" language. Maybe they should have implemented the flash runtime in a "safe" languange... like java? or javascript? But wait, those are also implemented in an "unsafe" language!
Yes, there are "safe" languages which are compiled to machine code by a compiler written in that "safe" language. But there are still horrific security bugs which are not related to memory safety, in feature-packed super-popular web-facing software, like Rails or various PHP frameworks, where they automatically take some part of a request and inject variables in execution scope or even put user input through a yaml parser which will instantiate objects with constructors.
Using C isn't guaranteed to make software insecure (OpenBSD and DJB demonstrate that), while not using C isn't guaranteed to make software secure. Maybe it helps, maybe a lot. But you also need to care about code quality and security, and understand your own level of competence, and do the right thing.
It seems evident that if you care a lot about the features and backwards-compatibility with those features and not about code quality for a number of years, then even if you later care about security (and thus code quality), it's too late. The mess is too big for your organization to fix it.
> But wait, those are also implemented in an "unsafe" language!
The typical remark from those that don't get how compilers work.
There are Java compilers implemented in Java, just because OpenJDK isn't one of them it doesn't change the fact that they do exit.
Also why does the OpenJDK use C++ then?
Historically accident, the compiler/JIT weren't never bootstraped by Sun so the code lives on, but it gets replaced by Java code in each JDK release, step by step.
> Using C isn't guaranteed to make software insecure (OpenBSD and DJB demonstrate that)
Like OpenSSH? Nice proof of writing secure software in C.
Yes, there are logical security errors that plague languages even like Ada/SPARK.
However in 2015 we shouldn't be fighting against bounds errors and buffer exploits when it was already a solved problem in Algol.
The compiler isn't the issue here, the runtime is, and runtimes inherently have to be written in unsafe code because the underlying hardware architecture and operating system APIs are themselves unsafe. (With the exception of some very obscure and obsolete hardware from the 70s and 80s.)
It doesn't follow that anything but the lowest-level wrappers that call into the OS APIs have to be unsafe. Those wrappers can be a tiny fraction of the runtime code.
Buffer exploits are possible even in bounds-checked languages. Bounds that are checked are allocation bounds, not the logical bounds, which can still be misused on be incorrectly programmed. Some categories of bugs can be eliminated, making everything safe just by selecting any language is not actually possible.
Well, sure, but drawing the conclusion that there's no point in writing in a memory-safe language is like saying there's no point in building bridges instead of building rafts because bridges sometimes collapse.
I only came to C and C++ when using Pascal like languages wasn't any longer an option.
I know my way around systems programming with languages that offer stronger memory models.
I am also older enough to remember when the code produced by C compilers was seen as dog slow and not the speed daemons that everyone now takes them for.
To all of the Flash haters out there. You should dread the day YOUR code is looked at by thousands off smart hackers who want nothing more then to break it. As someone who was once a Flash hater myself I can understand your ignorance. Don't hate the tool, hate the people who abuse it.
"Outlaw chain saw so that no more massacres can happen!"
Flash it's self is not a resource hog. Its what you do in it, and how you do it. Its what happens when you give children chain saws. Usefulness? How do you measure that, how about the billions and billions of dollars that were generated by the app that use it?
I've been following tedu's blog and one of the interesting topics that came up in OpenBSD was W^X memory, which apparently didn't get along well with JIT compilers, so they devised a new memory protection scheme called now-or-never execution.
Outside of OpenBSD land, do you see either of these two (W^X, nonexec) being used in a future version of Adobe Flash Player? (and/or in Chrome/Firefox?)