The actual exploited bugs were mostly found in the OS but this is really about browsers. A contemporary browser pretty much exposes your entire OS to remote attacks. You want to exploit font interpretation? No problem, the browser will happily download your malicious font. There has to be a better way. This isn't working...
The better way is to use Qubes OS for security through isolation. You then use hardware virtualization to isolate untrusted application (including browsers) from the rest of system. Doesn't work on mobile though.
I saw; such a security-focused browser would naturally use only local, trusted fonts and strongly sandbox media playback/decode of any kind, probably in a different process. We need slow and safe before we can have fast and safe. Either is better than the fast and unsafe we have now. We should probably unfuck the dangerous morass that is turing-complete font file formats at some point, too.
The direction of webdev is webasm delivering full almost-desktop level apps and SPAs vs the documents with some minor scripting of the past.
Slow & safe javascript will simply not be adopted by the market because there is zero incentive to do so. Change the incentives and you will get the change you want.
uMatrix has been archived and is no longer maintained: https://news.ycombinator.com/item?id=24532973 https://github.com/gorhill/uMatrix I'm not sure what is supposed to replace it though.
uBlock in medium mode or higher https://github.com/gorhill/uBlock/wiki/Blocking-mode:-medium...
Diversity is low because of the massive amounts of capital Google has. Both in terms of money and power.
If a Web browser were easier to implement, we would have more than ~3 well maintained engines. In other words, why should Web require massive amounts of capital?
Feature creep. Everyone wants to leave a footprint in the world. Same thing with legislation.
The actual exploited bugs were mostly found in the OS but this is really about browsers. A contemporary browser pretty much exposes your entire OS to remote attacks. You want to exploit font interpretation? No problem, the browser will happily download your malicious font. There has to be a better way. This isn't working...
The only thing that comes to mind is having most websites be sites and not apps . Most sites don't need custom fonts, JavaScript, and CSS. If Firefox & Chrome had support for something lightweight like Gemini ( https://gemini.circumlunar.space/ ) then most sites could just use that. With that sort of setup, restrictions on the web like uMatrix would be a lot less painful because most sites wouldn't ever need to be wh…
>If Firefox & Chrome had support for something lightweight like Gemini (https://gemini.circumlunar.space/) then most sites could just use that.
But they wouldn't, because they couldn't track people.
A JIT will write to memory and then turn the executable bit on. https://en.wikipedia.org/wiki/W%5EX
you are implying this is the underlying cause for code execution exploit, it is not.
Actually with the font exploits an interpreter would be quite a bit safer. Many of the font exploit chains work by creating line vectors that result in an infinity or NaN throwing a floating point error (with the SeH handler already being overwritten). When running this by JIT... all of this is occurring on the physical CPU. If the floating point calculations were occurring inside an interpreter then the SEH chain can be protected by SEHOP/SAFESEH and the interpreter could implement bounds checks and while retaining the NX bit on everything executing.
I said this once and I'll say it again: To counter such threats we need a healthy heterogeneous ecosystem. According to the article, the attack would have been prevented by using Firefox, (because it relied on a Chrome CVE). It also did not work on Linux and presumably not on Apple's ARM CPUs. But unfortunately we don't get exponential security. Normally, one would expect that n variables (Browser, OS, CPU architectu…
Pretty sure the iOS exploits worked on Apple CPUs.
>I might just go back to pen and paper at this point. Maybe you kid, but... I've been using a physical calendar on the wall this year. I also replaced my Apple Watch with a Casio F-91W some time ago. You know what's really great? My calendar or watch never gets hacked and it's never unavailable because some overnight software update broke it! Sure, the F-91W technically runs software, but it has no connectivity. That…
I have a $12 flip phone, pay as you go, not in my name. It can't browse the web and if someone sends me binary data in a text message its shows up the same as if I read binary data in my terminal. The phone has no idea what to do with it. Battery life would be great if the did not remove the cell sites near me. I think this model was replaced by one that is $29 but its basically the same thing. Check Walmart or an eq…
I would do that also, if I could replace the live traffic of google maps. Did you find a solution to that, or do you just not need it?
you are implying this is the underlying cause for code execution exploit, it is not.
Actually with the font exploits an interpreter would be quite a bit safer. Many of the font exploit chains work by creating line vectors that result in an infinity or NaN throwing a floating point error (with the SeH handler already being overwritten). When running this by JIT... all of this is occurring on the physical CPU. If the floating point calculations were occurring inside an interpreter then the SEH chain ca…
a. closing one attack vector does not justify slowing down the entire world.
b. you can have the jit compile with any bound checks as you suggested, so still not justifying an interpreter. the only reason for an interpreter is simplicity, once you have a jit there's no logical reason to go back.
also when you say NX bit, you do know the interpreter is running code still. it's just doesn't have to be RW (actually jit don't either) which still allows for ROP. there has to be some very specific exploit for these things to have a dramatic effect (ie. can be vs. cannot be exploited) many times there will be several methods to exploit a vuln.
I said this once and I'll say it again: To counter such threats we need a healthy heterogeneous ecosystem. According to the article, the attack would have been prevented by using Firefox, (because it relied on a Chrome CVE). It also did not work on Linux and presumably not on Apple's ARM CPUs. But unfortunately we don't get exponential security. Normally, one would expect that n variables (Browser, OS, CPU architectu…
Diversity is a sign of health in an ecosystem. But, increasing diversity directly isn't really viable. Question is, why is diversity low? In my opinion, Web, OSes and CPUs suffer from being overly complicated, closed-source ridden, non-modular systems-within-systems. Basicly, the opposite of what the Unix philosophy advocates.
I agree. They are too complicated. Some more work toward making better one will be helpful.
Protocols and instruction sets etc will need to be not too complicated, in addition to being open source and fully documented.