|
|
|
|
|
|
by rst
3266 days ago
|
|
|
To some of us, the "sprawling throw-it-over-the-wall approach to development" is the problem. Particularly when they decide to reimplement services instead of using battle-hardened code, and revive old bugs that haven't been seen in the wild in years. As has happened with their DNS resolver, which was initially shipped missing measures that everyone else had shipped years ago to deter cache poisoning, and had buffer overflow problems on top of that. There are not fundamental design flaws. They don't have to be, to be a problem. And it's a problem exacerbated by the developers' typical response to problem reports -- to try to transfer blame, or treat them as personal attacks, rather than dealing with the issue. An example of that is CVE-2017-1000082 -- a rare example of a real problem that was assigned a CVE number by request of someone other than the developer, because the developers are still insisting, after a week of well-deserved mockery, that it's not a problem (or not their problem, or something)... Refs: Buffer overflow: https://www.theregister.co.uk/2017/06/29/systemd_pwned_by_dn... Cache poisoning: http://seclists.org/oss-sec/2014/q4/592 |
|
|
This was discussed here: http://www.openwall.com/lists/oss-security/2017/07/02/1
> a rare example of a real problem that was assigned a CVE number by request of someone other than the developer
It's fairly common that the security researcher requests CVE. CVE request by an affected distro (which is what happened here) isn't anything unusual either.