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

131–140 of 151 posts

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

#131

Post by tomrittervg »

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.

This is true, but adding a sandboxing to browsers has been a huge part in driving up the difficulty/cost of browser exploits, and driving down the frequency of their use.

And also we'll pay for a bypass of the wasm sandbox. (Actually, looking at our table, I'm going to try and get the bountyamount upped...)

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

#132

Post by mikedelfino »

nullc wrote: post #122
mikedelfino wrote: post #92

Earlier quoted context omitted.

> a world where a random click from HN or reddit can't quietly compromise your entire computer Doesn't Flatpak also solve this?

No, flatpack is very much not a security sandbox.

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

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

#133

Post by neonsunset »

sunshowers wrote: post #124
neonsunset wrote: post #120

Earlier quoted context omitted.

C# doesn't have Send and Sync that is true. It frequently does not need either because it uses GC instead of affine types for automatic memory management. Synchronization is indeed "just don't write bugs", where Rust offers a massive upgrade, but .NET CoreCLR's memory model is more strict than C one, like object reference assignment having release semantics, so quite a few footguns are luckily avoided: https://github…

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

  lock (obj) {
    // critical section
  }
This, together with thread-safe containers provided by standard library (ConcurrentDictionary, ConcurrentStack, etc.) is usually more than enough.

What Rust offers in comparison is strong guarantee for complex scenarios, where you usually have to be much more hands-on. In C#, you can author types which e.g. provide "access lease", that look like 'using var scope = service.EnterScope(); ...`, where using turns into a try-finally block, where finally that calls .Dispose() on the scope is guaranteed to be executed.

It's a big topic, so if you have a specific scenario in mind - let me know.

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

#134

Post by neonsunset »

eqvinox wrote: post #129
high_na_euv wrote: post #125

Earlier quoted context omitted.

I had .net on prod linux since 2018 and it works very fine seamlessly, web apps. Things changed after core

I'm happy to hear of your experience, but all we have at this point is a sample size of 2 with one good experience and one poor one… (I've tried [and failed/given up after about 2 weeks] to get a .net desktop application to build on Linux.)

I hope you haven't been trying to use Mono or something obscure for this, which unfortunately happens from time to time.

If you have .NET SDK installed (you can get it with apt/dnf install dotnet8 or dotnet-sdk-8.0), you only need the following:

  dotnet new install Avalonia.Templates
  dotnet new avalonia.app
  dotnet run
If you don't like XAML, you can use https://github.com/AvaloniaUI/Avalonia.Markup.Declarative to write declarative SwiftUI-like code. You can also use F# if that's your cup of tea: https://github.com/fsprojects/Avalonia.FuncUI.

If you prefer GTK, there are rich GObject bindings that are a successor to GTK#: https://gircore.github.io/

Here are samples that demonstrate basic GTK4 usage scenarios: https://github.com/gircore/gir.core/tree/main/src/Samples/Gt...

All this should require less than 10 minutes including setup and such.

Lastly, I want to make a disclaimer that you do not need C# Dev Kit extension (which requires an account that annoys many people, including me) for VS Code, only the base C# one, which is what gives you language server, debugger, etc. If you are using VSCodium which cannot use closed-source vsdbg component that the base extension uses, you can replace it with https://github.com/muhammadsammy/free-vscode-csharp which uses open-source debugger from Samsung instead. It can be rough around the edges but works well enough in standard scenarios. Just don't use Debugger.WriteLine over Console. :D

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

#135

Post by jjuran »

tomrittervg wrote: post #130
btdmaster wrote: post #34

Earlier quoted context omitted.

Ticket in Tor Browser: https://gitlab.torproject.org/tpo/applications/tor-browser/-... It seems to be JavaScript-free from the description, which makes it even scarier. Imagine the libwebp decoder bug except embedded media blocking doesn't really work (who blocks CSS?).

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?

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

#136

Post by EasyMark »

mikedelfino wrote: post #132
nullc wrote: post #122

Earlier quoted context omitted.

No, flatpack is very much not a security sandbox.

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

repeated myself somehow

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

#137

Post by EasyMark »

mikedelfino wrote: post #132
nullc wrote: post #122

Earlier quoted context omitted.

No, flatpack is very much not a security sandbox.

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.

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

#138

Post by nullc »

mikedelfino wrote: post #132
nullc wrote: post #122

Earlier quoted context omitted.

No, flatpack is very much not a security sandbox.

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

it's easy for something with arbitrary code execution to escape the sandboxing. https://hanako.codeberg.page/

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

#139

Post by nullc »

prmoustache wrote: post #126
nullc wrote: post #121

Earlier quoted context omitted.

I dunno about that? do you use more than one gpu intensive task at a time?

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 general my view is that qubes has serious operating costs but they are much less than I anticipated.

And whats the real alternative? It's still better than carrying 5 laptops in terms of ease and usability.

We live in a world where browsers are constantly required but where their probably hasn't been a single day since their initial releases where Chrome and Firefox were without a RCE vulnerability (though often not a publicly known one).

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

#140

Post by mikedelfino »

nullc wrote: post #138
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.

it's easy for something with arbitrary code execution to escape the sandboxing. https://hanako.codeberg.page/

I couldn't reproduce the tty example, but it might as well be a mistake on my side. Other than this, the sandboxing spec itself is as safe as I'd expect. I reckon that Wayland applications not packaged to require $HOME access or some dbus services are not known to escape the sandbox. This seems to be the case of Firefox, afaict.
Post reply on HN