Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla fixes Firefox zero-day actively exploited in attacks

bleepingcomputer.com

Post reply on HN
Print view View original

141–150 of 151 posts

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#141

Post by sunshowers »

neonsunset wrote: post #133
sunshowers wrote: post #124

Earlier quoted context omitted.

Is there anything in C# which ensures what Rust does statically, that you must acquire a lock to access data protected by a mutex? Rust also has MutexGuard not be sendable i.e the mutex won't be released on a different thread from which it is acquired. With traditional mutex APIs it's just far too easy to get it wrong. I think you just have to structure your thread-related APIs to be misuse resistant. As humans we're…

> I think you just have to structure your thread-related APIs to be misuse resistant The premise of this stays. C# approaches this in a more traditional way, with exposing the set of synchronization primitives. It's a step above C and, usually, C++ still because you don't need to e.g. have an atomic reference counting for objects shared by multiple threads. Concurrent access itself can be protected as easily as doing…

Thanks! To be fair, there are certain advanced scenarios which Rust's mutex model can't handle either -- sometimes you want to protect writes via a mutex, but allow reads without them (maybe you're okay with torn state on reads). This is a rare, expert use case with architecture-specific considerations that must be handled with care.

I do think Rust's mutexes handle almost every use case that can be thrown at them, though, and in a way where it's next to impossible to get it wrong. I think if you're writing a browser engine in the 21st century you should bake in parallelism and concurrency from the start, and Rust is the most suitable language to do that in.

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#142

Post by petertodd »

nullc wrote: post #139
prmoustache wrote: post #126

Earlier quoted context omitted.

Please define GPU intensive. Using a gpu for video decoding can mean smaller battery usage in some cases. Also it is not only about doing these tasks at a time, but if you need to shut down to be able to start another VM context because they can't be used concurrently it makes it very tedious user experience.

A normal qubes user workflow doing all your gpu requiring stuff in a single appvm-- you're not forced into isolation that doesn't work for you. But you're also not running qubes if minimizing battery usage is a high priority for you. As far as the tedium, perhaps a little, but bringing up a terminal on a non-currently-running app vm takes about 5 seconds for me, so it's faster than you might expect. I think in genera…

USB-C PD has made laptop battery life less of an issue than it used to be, because carrying around extra battery life with external batteries is so easy. I typically carry one or two of these in my backpack: https://iniushop.com/products/iniu-b64-140w-27-000mah-fast-c...

That's enough for hours of intensive usage on my laptop, like running nodes and compiling stuff. And as you know, I run Qubes too!

I originally got an external battery when I went to Ukraine while Russia was trying to destroy the electricity grid; I got the largest battery I could legally carry on a plane (typically 100Wh is the limit). I ended up liking them enough to buy a few more.

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#143

Post by flohofwoe »

guappa wrote: post #128
flohofwoe wrote: post #27

Earlier quoted context omitted.

I can't find the link right now but I seem to remember that Firefox already replaced some internal native subsystems with the same code compiled to WASM - or maybe even compiled to WASM and then translated back to C, which basically adds a runtime memory safety layer to unsafe C code at the cost of some performance (I think it was a couple of media codecs, but not sure). Not sure why you think that WASM is less secur…

> there's no way for this to do damage outside the WASM sandbox java applets promised a sandbox and then we had years of continuous vulnerabilities of escaping said sandbox.

Java applets didn't sandbox shit though, because you could call straight into your own native code via JNI (I know because I used exactly that approach to integrate a Win32 game client into browsers). The only thing that the applet launcher did was asking if it is ok to run the applet.

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#144

Post by guappa »

flohofwoe wrote: post #143
guappa wrote: post #128

Earlier quoted context omitted.

> there's no way for this to do damage outside the WASM sandbox java applets promised a sandbox and then we had years of continuous vulnerabilities of escaping said sandbox.

Java applets didn't sandbox shit though, because you could call straight into your own native code via JNI (I know because I used exactly that approach to integrate a Win32 game client into browsers). The only thing that the applet launcher did was asking if it is ok to run the applet.

You're probably thinking of microsoft java. I was talking about the proper java.

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#145

Post by nullc »

EasyMark wrote: post #137
mikedelfino wrote: post #132

Earlier quoted context omitted.

Do you mean you don't trust it? Because they do describe its sandboxing as a security feature.

flatpak or firejail would have protected you from this vulnerability, not sure what they're on about here. They are 100% proof against everything of course.

The firefox flatpak has write access to your home directory. So it can simply edit your bashrc even if there are no more direct escapes, no?

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#146

Post by mikedelfino »

nullc wrote: post #145
EasyMark wrote: post #137

Earlier quoted context omitted.

flatpak or firejail would have protected you from this vulnerability, not sure what they're on about here. They are 100% proof against everything of course.

The firefox flatpak has write access to your home directory. So it can simply edit your bashrc even if there are no more direct escapes, no?

Firefox Flatpak has neither write or read permission to your home directory. At least that's my take from browsing file:///home/myuser. If you try to open or save a file using the native dialogs, you do grant the appropriate permission on demand, but that's using the xdg portal, outside the app scope, specifically designed for this.

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#147

Post by a_vanderbilt »

jjuran wrote: post #135
tomrittervg wrote: post #130

Earlier quoted context omitted.

The vulnerability did require JavaScript to trigger. I think it would be a labor of love and craftsmanship to exploit a content process today without using JavaScript.

> The vulnerability did require JavaScript to trigger. Can you back this up with a citation?

He works (or recently worked) for Mozilla on security-related projects. The code commit fixing the issue was isolated to the /dom/ directory in the source tree, and Firefox does not support CSS Animation Timelines. The Animation Timelines code is not directly accessed by web devs, and it appears the only way to execute that code is via the JS API for Animation Timelines. I'm not a web security expert, but the signs seem to point to him being correct.

Once again, JS proves to be a security risk.

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#148

Post by 3np »

fransje26 wrote: post #37
nullc wrote: post #35

Regain your ability to sleep at night: https://www.qubes-os.org/

From your experience, what are the system requirements needed to use that as comfortably as your daily driver?

It depends on how you use it. The more you leverage its strengths (by splitting out AppVMs), the larger the overhead in memory and CPU.

I've run through a few QubesOS installations over the years and would say for me it's ~2x memory and a couple of cores overhead.

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#149

Post by fransje26 »

3np wrote: post #148
fransje26 wrote: post #37

Earlier quoted context omitted.

From your experience, what are the system requirements needed to use that as comfortably as your daily driver?

It depends on how you use it. The more you leverage its strengths (by splitting out AppVMs), the larger the overhead in memory and CPU. I've run through a few QubesOS installations over the years and would say for me it's ~2x memory and a couple of cores overhead.

So aim for at least 64GB of memory?

Re: Mozilla fixes Firefox zero-day actively exploited in attacks

#150

Post by 3np »

fransje26 wrote: post #149
3np wrote: post #148

Earlier quoted context omitted.

It depends on how you use it. The more you leverage its strengths (by splitting out AppVMs), the larger the overhead in memory and CPU. I've run through a few QubesOS installations over the years and would say for me it's ~2x memory and a couple of cores overhead.

So aim for at least 64GB of memory?

Yeah. I have to stay conscious of resource usage and can't run all the stuff I'd really want (which TBF is a bit) at 32.
Post reply on HN