CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

121

cchizhik-pyzhik about 2 hours ago 30 commentsRead Article on lists.thekelleys.org.uk

FR version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

38% Positive

Analyzed from 1180 words in the discussion.

Discussion (30 Comments)Read Original on HackerNews

strenholme•40 minutes ago

Shameless plug time:

My own MaraDNS has been extensively audited now that we’re in the age of AI-assisted security audits.

Not one single serious security bug has been found since 2023. [1]

The only bugs auditers have been finding are things like “Deadwood, when fully recursive, will take longer than usual to release resources when getting this unusual packet” [2] or “This side utility included with MaraDNS, which hasn’t been able to be compiled since 2022, has a buffer overflow, but only if one’s $HOME is over 50 characters in length” [3]

I’m actually really pleased just how secure MaraDNS is now that it’s getting real in depth security audits.

[1] https://samboy.github.io/MaraDNS/webpage/security.html

[2] https://github.com/samboy/MaraDNS/discussions/136

[3] https://github.com/samboy/MaraDNS/pull/137

washingupliquid•about 1 hour ago

Maybe this is the kick in the ass Debian needs to upgrade the embarrassingly ancient dnsmasq in "stable" because while I can't think of any new features, the latest versions contain many non-CVE bug fixes.

But I doubt it, they will lazily backport these patches to create some frankenstein one-off version and be done with it.

Before anyone says "tHaT's wHaT sTaBlE iS fOr": they have literally shipped straight-up broken packages before, because fixing it would somehow make it not "stable". They would rather ship useless, broken code than something too new. It's crazy.

zrm•about 1 hour ago

They're not going to put a newer version in stable. The way stable gets newer versions of things is that you get the newer version into testing and then every two years testing becomes stable and stable becomes oldstable, at which point the newer version from testing becomes the version in stable.

The thing to complain about is if the version in testing is ancient.

koverstreet•35 minutes ago

No, that's exactly the thing to complain about.

That whole model dates to before automated testing was even really a thing, and no one knew how to do QA; your QA was all the people willing to run your code and report bugs, and that took time. Not to mention, you think the C of today is bad? Have you looked at old C?

And the disadvantage is that backporting is manual, resource intensive, and prone to error - and the projects that are the most heavily invested in that model are also the projects that are investing the least in writing tests and automated test infrastructure - because engineering time is a finite resource.

On top of that, the backport model heavily discourages the kinds of refactorings and architectural cleanups that would address bugs systemically and encourage a whack-a-mole approach - because in the backport model, people want fixes they can backport. And then things just get worse and worse.

We'd all be a lot better off if certain projects took some of the enthusiasm with which they throw outrageous engineering time at backports, and spent at least some of that on automated testing and converting to Rust.

zrm•17 minutes ago

> That whole model dates to before automated testing was even really a thing, and no one knew how to do QA; your QA was all the people willing to run your code and report bugs, and that took time.

That's not what it's about.

What it's about is, newer versions change things. A newer version of OpenSSH disables GSSAPI by default when an older version had it enabled. You don't want that as an automatic update because it will break in production for anyone who is actually using it. So instead the change goes into the testing release and the user discovers that in their test environment before rolling out the new release into production.

> On top of that, the backport model heavily discourages the kinds of refactorings and architectural cleanups that would address bugs systemically and encourage a whack-a-mole approach - because in the backport model, people want fixes they can backport.

They're not alternatives to each other. The stable release gets the backported patch, the next release gets the refactor.

But that's also why you want the stable release. The refactor is a larger change, so if it breaks something you want to find it in test rather than production.

jeroenhd•28 minutes ago

If you want that, you don't want Debian. Other people do.

Some people will even run Debian on the desktop. I would never, but some people get real upset when anything changes.

Debian does regularly bring newer versions of software: they release about every two years. If you want the latest and greatest Debian experience, upgrade Debian on week one.

From your description, you seem to want Arch but made by Debian?

wolttam•40 minutes ago

Looks like the version in stable is 2.91, which was released within a couple months of trixie. It's not 'ancient' by any stretch.

FWIW the fixes referenced here are already fixed in trixie: https://security-tracker.debian.org/tracker/source-package/d...

braiamp•34 minutes ago

Yeah was about to comment, parent says "if it is ancient", it is not. So the root comment is nothing burger. Stable has 1 release cycle old, and depending on how things play out, testing may have 2.93 or later anyways.

wolttam•39 minutes ago

I dunno, 2.92 seems to bring in some new features and changes that would not typically be brought into a stable release: https://thekelleys.org.uk/dnsmasq/CHANGELOG

afarviral•about 1 hour ago

What if the new release which contains the fixes has new dependencies and those also have new dependencies? I assume they have to Frankenstein packages sometimes to maintain the borders of the target app while still having major vulns patched right in stable.

882542F3884314B•about 1 hour ago

https://xchglabs.com/blog/dnsmasq-five-cves.html

romaniitedomum•about 2 hours ago

To quote a famous (in certain circles) bowl of petunias, "oh no, not again!"

antod•about 1 hour ago

Are you saying this is Arthur Dent's fault? (again)

washingupliquid•about 1 hour ago

It's a good thing this software isn't used in millions of devices which almost never receive updates.

amiga386•about 1 hour ago

It's more of a good thing that, in most cases, it's on devices that won't send it any packets unless a client first authenticates to a Wi-Fi station or physically plugs into an Ethernet port.

xydac•about 1 hour ago

some of these would have made to embedded hardwares, making updates more challenging if say you were to flash an update.

mrbluecoat•28 minutes ago

> The tsunami of AI-generated bug reports shows no signs of stopping, so it is likely that this process will have to be repeated again soon.

Welcome to the new world order.

dist-epoch•about 1 hour ago

How bad is it if someone infects my home router using such a thing? They can MITM non-encrypted requests, but there are not a lot of those, right?

What else can they do, assuming the computers behind the router are all patched up.

PhilipRoman•12 minutes ago

If you blindly TOFU ssh sessions, those can be pwned easily in many common use cases. Legacy software configurations like NFS with IP authentication will be bypassed. Realistically the most likely scenario is using your home as a VPN, or a DDOS node.

zrm•41 minutes ago

They can block traffic to update servers so the computers behind the router aren't all patched up, then exploit them. They also get access to all the IoT devices on the internal network. They can also use your router as a proxy so their scraping/attack traffic comes from your IP address instead of theirs.

It's definitely bad.

ck2•about 1 hour ago

if machine-learning can find all these holes

why can't machine-learning write a product from scratch that is flawless?

perlgeek•30 minutes ago

LLMs certainly make it more feasible to rewrite a product in a memory-safe language, eliminating a whole class of bugs.

Flawless software is hard for an LLM to write, because all the programs they have been trained on are flawed as well.

As a fun exercise, you could give a coding agent a hunk of non-trivial software (such as the Linux kernel, or postgresql, or whatever), and tell it over and over again: find a flaw in this, fix it. I'm pretty sure it won't ever tell you "now it's perfect" (and do this reproducibly).

chromacity•17 minutes ago

If humans can find bugs, why can't humans write flawless code?

Whatever the answer to that conundrum might be, LLMs are trained on these patterns and replicate them pretty faithfully.

_flux•about 1 hour ago

Just because something is good at finding bugs, it may not find all the bugs. Finding a bug only tells you there was one bug you found, it doesn't tell if the rest is solid.

yjftsjthsd-h•about 1 hour ago

Who said it can't? https://news.ycombinator.com/item?id=47759709 appears to be a nearly flawless (per spec) zip implementation.

tclancy•29 minutes ago

Because the problem is asymmetric: the attacker only needs to find one hole at one time. The defender has to be flawless forever.

hnlmorg•about 1 hour ago

It’s easier to break something than it is to make something that cannot be broken.

jonhohle•34 minutes ago

Have you ever met a security engineer? I’ve never met one who was also a good engineer (not saying they don’t exist, I just haven’t met one). Do they find vulnerabilities? Sure. Could they write the tools they use to find vulnerabilities, most probably not.