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

Hardening Firefox with Claude Mythos Preview

hacks.mozilla.org

Post reply on HN
Print view View original

91–100 of 176 posts

Re: Hardening Firefox with Claude Mythos Preview

#91

Post by Yoric »

nirui wrote: post #65
IainIreland wrote: post #21

Earlier quoted context omitted.

I work at Mozilla; I fixed a bunch of these bugs. In general, I would say that our use of "vulnerability" lines up with what jerrythegerbil calls "potential vulnerability". (In cases with a POC, we would likely use the word "exploit".) Our goal is to keep Firefox secure. Once it's clear that a particular bug might be exploitable, it's usually not worth a lot of engineering effort to investigate further; we just fix i…

How about this: a "vulnerability" is a "vulnerability", but after it was identified and verified to cause problem, that's when it should be called a "bug", because it could make the software do unwanted things.

When I worked at Mozilla, _everything_ was called a bug, whether it was a software issue, a problem in the office or some paperwork missing.

Much as GitHub calls everything an "issue" and GitLab a "work item".

Re: Hardening Firefox with Claude Mythos Preview

#92

Post by tialaramex »

jeroenhd wrote: post #88
tialaramex wrote: post #40

They've only linked a few tickets, so of course maybe when we see all 271 actual distinct things the insight won't apply but all those I examined ended up as some C++ code with a nasty bug in it. Firefox is written in several languages, only about 25% of it is in C++ but every single one of these issues seems to touch the C++.

It's possible Mythos is a lot better at finding vulnerabilities in C++ code than it is for other languages. After all, these models are also based on pre-existing security analysis. From what I can tell, a lot of these bugs were hardly C++-specific, they just happened in C++ code. Even the most secure Rust can't magically catch things like TOCTOU issues.

> Even the most secure Rust can't magically catch things like TOCTOU issues

I suppose it depends what the word "magically" means. A ToCToU race is because you imagined things wouldn't change but they did and in Rust you actually do write fewer patterns with this mistake because of the Mutable xor Aliased rule. If we have at least one immutable reference to a Goose then Rust isn't OK with anybody mutating the Goose, your safe Rust can't do that and unsafe Rust mustn't do that. So the ToCToU race caused by "Oops I forgot somebody else might change the Goose" is less likely because you were made to wrestle with this problem during design - the safe Rust where you just forgot about this doesn't compile.

Re: Hardening Firefox with Claude Mythos Preview

#93

Post by grumbelbart2 »

benced wrote: post #67

Reading this article in the context of the Zig folks refusing to even consider LLM-generated bugs certainly shapes my perspective on what technologies will be in my toolchain.

Both are right and it depends on which model you use and who submits those bugs. The capabilities of leading models went from 99% noise to 99% valid bugs in essentially a few months. Some projects are flooded with the former and need to take precautions to avoid essential DoS attacks on the maintainers.

Re: Hardening Firefox with Claude Mythos Preview

#94

Post by jeffparsons »

jerrythegerbil wrote: post #12

Again, and this is important: A bug is a bug. A “potential vulnerability” is a bug. A vulnerability is verifiable as having security implications with a proof of concept or other substantial evidence. Words matter. Bugs matter. It’s important to fix large amounts of bugs, just as it always has been, and has been done. Let that be impressive on its own, because it IS impressive. Mythos didn’t write 271 PoC for vulnera…

It may be worth noting that Claude can and will (if it believes you own the code, at least) produce PoC exploits for exploitable bugs that it finds.

My only source for this is personal experience, and no, I can't share any evidence of it.

Re: Hardening Firefox with Claude Mythos Preview

#95

Post by vga1 »

crummy wrote: post #24

Curious if people think LLMs will lead to more secure or less secure software in five years.

More secure, at least in the cases where the tools are properly applied.

But it also represents more easily available opportunities for blackhats to abuse against the projects where these tools were not being applied.

Re: Hardening Firefox with Claude Mythos Preview

#96

Post by nh2 »

IainIreland wrote: post #31
paulvnickerson wrote: post #23

Earlier quoted context omitted.

What types of vulnerabilities was it finding? Cross site scripting, privilege escalation, etc? Mostly memory corruption or any Javascript logic bugs?

I work on SpiderMonkey, so I mostly looked at the JS bugs. It was a smorgasbord of various things. Broadly speaking I'd say the most impressive bugs were TOCTOU issues, where we checked something and later acted on it, and the testcase found a clever way to invalidate the result of the check in between. If you look closely at, say, this patch, you might get a sense of what I mean (although the real cleverness is in t…

Given the commit is 4 weeks old, will it eventually get comments?

The code before the patch does not look obviously wrong. Now, some more lines were added, but would you now say it now looks less obviously wrong, or more obviously correct?

It seems that the invariants needed here are either in some person's heads, or in some document that is not referenced.

Reading the code for the first time, the immediate question is: "What other lines might be missing? How can I figure?"

If the "obviously correct" level of the code does not increase for a human reviewer, how is it ensured that a similar problem will not arise in the future? Or do we need more LLM to tell us which other lines need to be added?

Re: Hardening Firefox with Claude Mythos Preview

#98

Post by freedomben »

sfink wrote: post #73
nirui wrote: post #65

Earlier quoted context omitted.

How about this: a "vulnerability" is a "vulnerability", but after it was identified and verified to cause problem, that's when it should be called a "bug", because it could make the software do unwanted things.

At Mozilla, everything is called a bug. It's what other systems call an "issue". So it's too late for your terminology at Mozilla. (Example: I have a bug to improve the HTML output of my static analysis tool. There is nothing incorrect or flawed about the current output.) At Mozilla, but not everywhere: exploits are a subset of vulnerabilities are a subset of bugs.

Fwiw i think this is right. A bug is anything that doesn't do what you want it to do, and nobody should want a vulnerability in their software

Re: Hardening Firefox with Claude Mythos Preview

#99

Post by freedomben »

jeffparsons wrote: post #94
jerrythegerbil wrote: post #12

Again, and this is important: A bug is a bug. A “potential vulnerability” is a bug. A vulnerability is verifiable as having security implications with a proof of concept or other substantial evidence. Words matter. Bugs matter. It’s important to fix large amounts of bugs, just as it always has been, and has been done. Let that be impressive on its own, because it IS impressive. Mythos didn’t write 271 PoC for vulnera…

It may be worth noting that Claude can and will (if it believes you own the code, at least) produce PoC exploits for exploitable bugs that it finds. My only source for this is personal experience, and no, I can't share any evidence of it.

Are you certified for high risk cyber uses? If so then you're correct. If not, then it does not match my experience

Re: Hardening Firefox with Claude Mythos Preview

#100

Post by freedomben »

kakacik wrote: post #83
Diti wrote: post #2

I hope to see the day when (or if) the LLMs get so good at spotting and fixing bugs that all that’s left for the Firefox engineers to do is to focus on adding new features. This isn’t sarcasm. Firefox deserves to be used more. Most people I know don’t use it because “Chrome does almost everything better”, and Firefox can’t compete with the other browsers’ roadmaps.

Chrome ain't better in any meaningful way for >99% of use cases. Heck, I am a dev and I use FF with ublock origin only, for past... 10 years? Same with my wife, after I've explained things to her and she understood how different internet experience can be thats the primary browser. So please don't put the argument like 'here is crappy underdog but please use it because monopoly is bad and google is a bit evil', its f…

Agreed, though many websites only test on Chrome and are unusable on Firefox. Ramp.com and mailgun come immediately to mind. Zoom also won't let you join with browser on Firefox. There's enough that I have to keep a chrome available for those types of sites. It shouldn't be this way, but it is
Post reply on HN