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 please just how secure MaraDNS is now that it’s getting real in depth security audits.
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.
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.
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.
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.
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.
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.
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 please 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
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.
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
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.
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...
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.
https://xchglabs.com/blog/dnsmasq-five-cves.html
To quote a famous (in certain circles) bowl of petunias, "oh no, not again!"
Are you saying this is Arthur Dent's fault? (again)
some of these would have made to embedded hardwares, making updates more challenging if say you were to flash an update.
It's a good thing this software isn't used in millions of devices which almost never receive updates.
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.
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.
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.
if machine-learning can find all these holes
why can't machine-learning write a product from scratch that is flawless?
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.
It’s easier to break something than it is to make something that cannot be broken.
Who said it can't? https://news.ycombinator.com/item?id=47759709 appears to be a nearly flawless (per spec) zip implementation.