Live data from Hacker News

CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

lists.thekelleys.org.uk

81–90 of 256 posts

Re: CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

#81

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 broke…

You don't have to use Debian stable, if you'd prefer Ubuntu every 6 months, or Fedora (6 months? 9 months?), or even Arch Linux updated daily ...

I use Arch on my laptop, when I got it 2 years ago the amd gpu was a bit new so it was prudent to get the latest kernel, mesa, everything. Since I use it daily it's not bad to update weekly and keep on top of occasional config migrations.

I use Debian stable on my home server, it's been in-place upgraded 4-ish times over 10 years. I can install weekly updates without worrying about config updates and such. I set up most stuff I wanted many years ago, and haven't really wanted new features since, though I have installed tailscale and jellyfin from their separate debian package repos so they are very current. It does the same jobs I wanted it to do 8 years ago, with super low maintenance.

But if you don't want Debian stable, that's fine. Just let others enjoy it.

Re: CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

#82

Earlier quoted context omitted.

If package maintainers were always fine upstanding package maintainers as you imagine them to be I wouldn't be complaining, but I have in fact had Debian ship my software and screw it up and gotten a flood of bug reports, so... :) I think you need to chill out. Relicensing the way you suggest would be _quite_ the hostile act, and I'm not going to that either. But I am an engineer, so of course I'm going to talk about…

> I am an engineer, so of course I'm going to talk about engineering best practices when it comes up. The trouble is you seem to be assuming that best practices for you, in your opinion, also apply to everyone else. They don't. Not everyone sees things the way you do or is facing the same issues or is making the same set of tradeoffs. There are downsides to what debian does but there are also upsides. At this point,…

We're in the middle of a huge spike in LLM discovered security vulnerabilities, which means not everything will get assigned a CVE, a lot of people are watching repositories to look for exploitable bugs, and in the frenzy of backporting that people are now having to do things will get missed.

I wager it's only a matter of time before we see a mass rooting event that hits Debian hard while everyone running something more modern has already been patched.

I think that might be what cuts down on the grandstanding about "freedoms" and "that's how we've always done things". You certainly are, up until it becomes a public nuisance.

Re: CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

#83

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 ha…

MaraDNS is much less popular than dnsmasq though.

I have several libraries that I've written. Not one single serious security bug in them has been found since 1991. Granted, nobody uses my libraries...

Not to diminish your team's achievement! :D But it's important to contextualize claims like this with information about what your userbase looks like

Re: CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

#84
post #66

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 ha…

Well, as you bundle Lua 5.1 (as Lunacy), instead of making a library and loading it, and you bundled the 2012 version, you're probably affected by CVE-2014-5461 and others. Lua hasn't been security fix free.

Unless the service accepts Lua code from the internet (and that would be a completely insane thing), the CVE-2014-5461 will not apply. And while I have not reviewed every Lua CVE, I bet most (all?) of then require a specifically crafted code, or at least highly-complex user input (such as arbitrary json)

It's important to look at the actual vulnerability at the context, and not just list any CVE which matches by version.

Re: CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

#85

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 broke…

You can always ask the Debian project for your money back.

[deleted]

Re: CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

#86

Earlier quoted context omitted.

> I am an engineer, so of course I'm going to talk about engineering best practices when it comes up. The trouble is you seem to be assuming that best practices for you, in your opinion, also apply to everyone else. They don't. Not everyone sees things the way you do or is facing the same issues or is making the same set of tradeoffs. There are downsides to what debian does but there are also upsides. At this point,…

We're in the middle of a huge spike in LLM discovered security vulnerabilities, which means not everything will get assigned a CVE, a lot of people are watching repositories to look for exploitable bugs, and in the frenzy of backporting that people are now having to do things will get missed. I wager it's only a matter of time before we see a mass rooting event that hits Debian hard while everyone running something m…

No one is grandstanding about freedom here though? I claimed that the approach debian takes has both upsides and downsides. I stand by that. Personally I pull my networked services from testing while running stable on the host. I absolutely do not want constant churn of the filesystem code or drivers on my devices but I would also prefer not to run some franken build of ssh or apache or what have you. However I can also sympathize with others who need a more structured process and substantial lead time in staging prior to making major changes to production.

Why would you expect LLMs not to be simultaneously leveraged to catch backports that were missed or inadvertently broken?

Given recent headlines I think it's far more likely that we see a mass rooting event hit one or more of the bleeding edge rolling release distros or language ecosystems due to supply chain compromise. Running slightly out of date software has never been more attractive.

Re: CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

#87
That is pretty bad!

"a remote attacker capable of asking DNS queries or answering DNS queries can cause a large OOB write in the heap."

Malformed DNS response causes "infinite loop and dnsmasq stops responding to all queries."

Malicious DHCP request can cause buffer overlow.

Re: CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

#88
I think this is the breaking point where replacing our code written in C for code written in memory safe languages is becoming urgent.

The vast majority of vulnerabilities found recently are directly related to being written in memory unsafe languages, it's very difficult to justify that a DNS/DHCP server can't be written in rust or go and without using unsafe (well, maybe a few unsafe calls are still needed, but these will be a very small amount)...

Re: CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

#89
post #10

if machine-learning can find all these holes why can't machine-learning write a product from scratch that is flawless?

How do you define flawless though?

The CVEs here have their fair share of silly C problems, but also more rigid input validation and handling. These more rigid validations exclude stuff which may even be valid by the spec, but entirely problematic in practice.

As examples, take a look how many valid XML documents are practically considered unsafe and not parsed, for example due to recursive entity expansion. This renders the parsers not flawless and in fact not in spec.

Or, my favorite bait - there should be a maximum length limit on passwords. Why would you ever need a kilobyte sized password?

Re: CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

#90
post #84
post #66

Earlier quoted context omitted.

Well, as you bundle Lua 5.1 (as Lunacy), instead of making a library and loading it, and you bundled the 2012 version, you're probably affected by CVE-2014-5461 and others. Lua hasn't been security fix free.

Unless the service accepts Lua code from the internet (and that would be a completely insane thing), the CVE-2014-5461 will not apply. And while I have not reviewed every Lua CVE, I bet most (all?) of then require a specifically crafted code, or at least highly-complex user input (such as arbitrary json) It's important to look at the actual vulnerability at the context, and not just list any CVE which matches by vers…

Its important to maintain your dependencies, by say embedding Lua, rather than rebranding it and then claiming you have no security flaws.

If I can find a CVE that _may_ affect the stack in five minutes, what _actual_ problems lurk there?

You vendor Lua - thus, it _is_ your responsibility to review every Lua CVE. You've set yourself up as the maintainer by vendoring.

Post reply on HN