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

Significant raise of reports

lwn.net

Post reply on HN
Print view View original

91–100 of 164 posts

Re: Significant raise of reports

#91

Post by tptacek »

IshKebab wrote: post #74
chromacity wrote: post #70

> people will finally understand that security bugs are bugs, and that the only sane way to stay safe is to periodically update, without focusing on "CVE-xxx" Linux devs keep making that point, but I really don't understand why they expect the world to embrace that thinking. You don't need to care about the vast majority of software defects in Linux, save for the once-in-a-decade filesystem corruption bug. In fact, t…

Yeah that attitude really makes no sense, and I don't see why AI finding security bugs would make people "finally understand". I suspect it's just an excuse for Linux's generally poor security track record.

Everything has a poor security track record. That's the point.

Re: Significant raise of reports

#92

Post by franktankbank »

hyperpape wrote: post #86
franktankbank wrote: post #82

Earlier quoted context omitted.

If you don't personally review every line then you are already trusting blindly.

As blind as my belief that Asia exists, because I haven't personally navigated there. Hell, I've used electricity (using it right now), but I couldn't do the experiments you need to do to get myself to an 1850s level of understanding of how it works, much less our current level. I trust that Linux has a process. I do not believe it is perfect. But it gives me a better assurance than downloading random packages from P…

I get what you are saying but as you said, if you are already under attack you can't trust your own computer, you just hope that you aren't downloading another exploit/bogus update. Real software I imagine is not so easy to pwn so completely but I don't know.

Re: Significant raise of reports

#93

Post by miki123211 »

LatencyKills wrote: post #69
nradov wrote: post #64

Earlier quoted context omitted.

From the user perspective, Windows and Office certainly crashed more frequently back then. I don't mean that as a criticism of the Microsoft developers at the time: they did some great work within severe constraints. But overall the product quality is far better now.

I wouldn't take that as criticism; you are 100% correct. But that instability was a direct result of the issues I mentioned above: the ring transition protection/implementation was absolutely horrible; 3rd-party developers would discover a useful function in NTDLL and start using it in unintended ways, etc. Do you remember the CSRSS Backspace Bug? [0] A simple: printf("hung up\t\t\b\b\b\b\b\b"); from ring-3 would res…

I can't imagine how much of a breath of fresh air Python / Java must have been if you were used to write typical business crud apps (and server software) in C/C++ (with no sanitizers / modern tooling to speak of).

Re: Significant raise of reports

#95

Post by the__alchemist »

chromacity wrote: post #70

> people will finally understand that security bugs are bugs, and that the only sane way to stay safe is to periodically update, without focusing on "CVE-xxx" Linux devs keep making that point, but I really don't understand why they expect the world to embrace that thinking. You don't need to care about the vast majority of software defects in Linux, save for the once-in-a-decade filesystem corruption bug. In fact, t…

Details are important, but my mental model has settled as: Security bugs are being use in a manner to how politicians use think of the children. It's used as an auto-win button. There are things to me that compete with them in priorities. (Performance, functionality, friction, convenience, compatibility etc); it's one thing to weigh. In some cases, I am asking: "Why is this program or functionality an attack surface? Why can someone on the internet write to this system?"

Many times, there will be a system that's core purpose is to perform some numerical operations, display things in a UI, accept user input via buttons etc, and I'm thinking "This has a [mandatory? automatic? People are telling me I have to do this or my life will be negatively affected in some important way?] security update? There's a vulnerability?" I think: Someone really screwed up at a foundational requirements level!.

Re: Significant raise of reports

#96

Post by akerl_ »

tptacek wrote: post #91
IshKebab wrote: post #74

Earlier quoted context omitted.

Yeah that attitude really makes no sense, and I don't see why AI finding security bugs would make people "finally understand". I suspect it's just an excuse for Linux's generally poor security track record.

Everything has a poor security track record. That's the point.

Well, except OpenBSD. They’ve only had two vulns in forever.

Re: Significant raise of reports

#97

Post by tptacek »

bri3d wrote: post #81
piinbinary wrote: post #44

I'd be very curious to know what class of vulnerability these tend to be (buffer overrun, use after free, misset execute permissions?), and if, armed with that knowledge, a deterministic tool could reliably find or prevent all such vulnerabilities. Can linters find these? Perhaps fuzzing? If code was written in a more modern language, is it sill likely that these bugs would have happened?

> Can linters find these? Perhaps fuzzing? That's what syzbot / syzkaller does, as mentioned in the article, with somewhat similar results to the AI-fuzzing that they've been experiencing recently. The issue that Linux maintainers have in general is that there are so many of these "strict correctness and safety" bugs in the Linux codebase that they can't fix them all at once, and they have no good mechanism to triage…

It's a bigger deal than that.

Academically, syzkaller is just a very well orchestrated fuzzer, producing random pathological inputs to system calls, detecting crashes, and then producing reproductions. Syzkaller doesn't "know" what it's found, and a substantial fraction of what it finds are "just" crashers that won't ever be weaponizable.

An LLM agent finding vulnerabilities is an implicit search process over a corpus of inferred vulnerability patterns and inferred program structure. It's stochastic static program analysis (until you have the agent start testing). It's generating (and potentially verifying) hypotheses about actual vulnerabilities in the code.

That distinction is mostly academic. The bigger deal is: syzkaller crashes are part of the corpora of inputs agents will use to verify hypotheses about how to exploit Linux. It's an open secret that there are significant vulnerabilities encoded in the (mostly public!) corpus of syzbot crash reproductions; nobody has time to fish them out. But agents do, and have the added advantage of being able to quickly place a crash reproduction in the inferred context of kernel internals.

Re: Significant raise of reports

#98

Post by tptacek »

_se wrote: post #80
tyre wrote: post #79

I wish they wouldn’t call it “AI slop” before acknowledging that most of the bugs are correct. Let’s bring a bit of nuance between mindless drivel (e.g. LinkedIn influencing posts, spammed issues that are LLMs making mistakes) vs using LLMs to find/build useful things.

It can be correct and slop at the same time. The reporter could have reported it in a way that makes it clear a human reviewed and cared about the report. Slop is a function of how the information is presented and how the tools are used. People don't care if you use LLMs if they don't tell you can use them, they care when you send them a bunch of bullshit with 5% of value buried inside it. If you're reading something…

No it can't. These aren't "Show HN" posts about new programs people have conjured with Claude. They're either vulnerabilities or they're not. There's no such thing as a "slop vulnerability". The people who exploit those vulnerabilities do not care how much earlier reporters "gave a fuck" about their report.

This is in the linked story: they're seeing increased numbers of duplicate findings, meaning, whatever valid bugs showboating LLM-enabled Good Samaritans are finding, quiet LLM-enabled attackers are also finding.

People doing software security are going to need to get over the LLM agent snootiness real quick. Everyone else can keep being snooty! But not here.

Re: Significant raise of reports

#100

Post by miki123211 »

Sharlin wrote: post #9
nayroclade wrote: post #3

> I don't know how long this pace will last. I suspect that bugs are reported faster than they are written, so we could in fact be purging a long backlog Hopefully these same tools will also help catch security bugs at the point they're written. Maybe one day we'll reach a point where the discovery of new, live vulnerabilities is extremely rare?

Around 70% of security vulnerabilities are about memory safety and only exist because software is written in C and C++. Because most vulnerabilities are in newly written code, Google has found that simply starting writing new code in Rust (rather than trying to rewrite existing codebases) quickly brings the number of found vulnerabilities down drastically.

I find this interesting.

Curl's Daniel Stenberg claimed during his NDC talk that vulnerabilities in this project are 8 years old on average.

I wonder where the disconnect comes from.

Post reply on HN