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

CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

lists.thekelleys.org.uk

Post reply on HN
Print view View original

171–180 of 256 posts

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

#171

Post by bluedragon1221 »

Yokohiii wrote: post #156
unclejuan wrote: post #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 the…

The problem is the lack of talent that is willing to work on this, not the language. AI Security researchers at least do something. If it was so easy to rewrite everything in rust, I don't know why the response to this incidents isn't a rock solid replacement in rust, the next day. I tell you why that is. Working on these things doesn't give you stars on github.

That is a very pretentious opinion. Dnsmasq is a ubiquitous project, ~14 years old, and has maintainers that are very experienced in c and in the codebase. Telling them to rewrite in a language they are (maybe) unfamiliar with, even with the help of AI, will make these maintainers' experience worthless.

People seem to think that rewriting in rust just magically fixes all issues, but that's not how it works (See recent uutils CVEs). Rewrites tend to have more bugs because the code is new and hasn't been reviewed as much.

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

#172

Post by bayindirh »

kokada wrote: post #169
Orygin wrote: post #160

Earlier quoted context omitted.

How many CVEs in coreutils over the years? The project has the advantage of being old enough for them to be fixed. Call me when the rust rewrite has been there that long and still has more CVEs than the GNU counterpart.

Not sure how reliable this site is, but if it is correct it looks like 10: https://www.cvedetails.com/vulnerability-list/vendor_id-72/p... . Maybe coreutils is so old that most security vulnerabilities was solved before CVE even existed. But I think this is also a good argument why we are replacing a solid piece of C code to Rust just because it is "memory safe" and then have lots of CVEs related to things like TOCTO…

People thinking that using a superior tool (on paper) enables them to automatically write better tools than the ones who are battle tested over the years baffles me to no end.

Yes, you can go further, possibly faster. OTOH, nothing replaces experience and in-depth knowledge. GNU Coreutils embodies that knowledge and experience. uutils has none, and just tries to distill it with tests against the GNU one.

...and they get 44 CVEs as a result in their first test.

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

#173

Post by BrandoElFollito »

binaryturtle wrote: post #43
strenholme wrote: post #19

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…

That's a bit shameless, indeed. dnsmasq has served me well for like an eternity in multiple setups for different use cases. As all software it has bugs. And once located those get fixed. Its author is also easy to communicate with. Why should I switch over to something way less proven? I'm quite sure your software also has bugs, many still not located. Maybe because it's less popular/ less well known nobody cares to…

> dnsmasq has served me well for like an eternity in multiple setups for different use cases. As all software it has bugs. And once located those get fixed. Its author is also easy to communicate with.

I concur. The last part, however, is quite worrisome. Dnsmasq is ran by one person, published on their own git and I did not see any information about other maintainers.

It is a super important (and great, and useful, and everything) software and i have fears of what will happen one day.

Sure, someone can clone and push to github but it may seriously fragment the ecosystem.

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

#174

Post by user3939382 »

unclejuan wrote: post #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 the…

Maybe the problem is the way we think of dynamic memory. “Oh I don’t know what my maximum size for this is going to be, everything has to be dynamic” Is that really true? Is it really the end of the world for programs to declare maximum acceptable sizes for their inputs, and after that error out or use a ring buffer? If sizes were known you could design around that when using them. Your ram bank is finite, why is every layer inside of it then designed to pretend to be infinite? The rust thing strikes me as a massive waste of time and doesn’t solve the fundamental problem of modeling our programs correctly for reality which is finite system resources, and not just memory. c.f. Chrome loading 4 GB models onto people’s machines.

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

#175

Post by BrandoElFollito »

washingupliquid wrote: post #8

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…

It depends on how you look at it. I use Debian stable in the smallet possible configuration because it is, well, stable. A rock on which I put docker to run actually useful services, which are upaded the way I want.

If I was to run dnsmasq on Debian, it would be in a container. Since I run Pihole (in a container), it kinda is.

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

#176

Post by hombre_fatal »

bayindirh wrote: post #172
kokada wrote: post #169

Earlier quoted context omitted.

Not sure how reliable this site is, but if it is correct it looks like 10: https://www.cvedetails.com/vulnerability-list/vendor_id-72/p... . Maybe coreutils is so old that most security vulnerabilities was solved before CVE even existed. But I think this is also a good argument why we are replacing a solid piece of C code to Rust just because it is "memory safe" and then have lots of CVEs related to things like TOCTO…

People thinking that using a superior tool (on paper) enables them to automatically write better tools than the ones who are battle tested over the years baffles me to no end. Yes, you can go further, possibly faster. OTOH, nothing replaces experience and in-depth knowledge. GNU Coreutils embodies that knowledge and experience. uutils has none, and just tries to distill it with tests against the GNU one. ...and they…

There was an article posted to HN recently that enumerated bugs in the rust rewrite.

Iirc the bugs had to do with linux system details like fs toctou and other things you'd only find out about in production.

Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs, so that every project doesn't have to relearn them at runtime. But the rewrite isn't pure downside.

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

#177

Post by [deleted] »

unclejuan wrote: post #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 the…

[deleted]

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

#178

Post by zamadatix »

strenholme wrote: post #146
zamadatix wrote: post #129

Earlier quoted context omitted.

I never used Qmail, so I won't comment on it, but I will say I absolutely consider djbdns narrow in scope as well (before accounting the Unix approach, utilized perhaps even more than in MaraDNS, to break that already narrowed scope down into even more focused binaries). I had believed (and continue to hold) DNS software containing, e.g., an authoritative DNS server which lacks native TCP or DNSSEC support falls squa…

The point of djbdns and qmail was this: It allowed administrators to run a local DNS server securely without needing to constantly patch the code. They were limited in scope, but were perfect for admins who valued security over features. In an era when DNS was otherwise a monoculture, djbdns was a welcome breath of fresh air. https://lwn.net/2001/0208/

Agreed, and that was a good use case + timing (at least for me a ways back :D). I.e. djbdns being narrow in scope isn't necessarily supposed to be a bad decision, it just doesn't serve as a counterexample to the narrow scope option as it was introduced to be.

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

#179

Post by bayindirh »

hombre_fatal wrote: post #176
bayindirh wrote: post #172

Earlier quoted context omitted.

People thinking that using a superior tool (on paper) enables them to automatically write better tools than the ones who are battle tested over the years baffles me to no end. Yes, you can go further, possibly faster. OTOH, nothing replaces experience and in-depth knowledge. GNU Coreutils embodies that knowledge and experience. uutils has none, and just tries to distill it with tests against the GNU one. ...and they…

There was an article posted to HN recently that enumerated bugs in the rust rewrite. Iirc the bugs had to do with linux system details like fs toctou and other things you'd only find out about in production. Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs, so that every project doesn't have to relearn them at runtime. But the rewrite isn't pure downside.

I'm personally not against Rust rewrites in principle. But doing them in this drive-by hostile manner, esp. with non-GNU licenses smells "hostile takeover" for me, and dismantling core free software utilities is not nice in general.

> Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs

I believe trying to make something idiot-proof just generates better idiots, so I prefer having thinner abstractions on the lower level for maintenance, simplicity and performance reasons. The real solution is better documentation, but who values good documentation?

Graybeards and their apprentices, mostly from my experience. I personally still live with reference docs rather than AI prompts, and it serves me well.

Post reply on HN