From 0-Day to Exploit - Buffer Overflow in Belkin N750 (CVE-2014-1635)(labs.integrity.pt)
labs.integrity.pt
From 0-Day to Exploit - Buffer Overflow in Belkin N750 (CVE-2014-1635)
https://labs.integrity.pt/articles/from-0-day-to-exploit-buffer-overflow-in-belkin-n750-cve-2014-1635/
3 comments
Side bar, who releases these? Is there a feed(s) that devops/sysadmin/people follow to get the CVE-X-Y reports or is it more ad-hoc/whoever finds them
Common Vulnerabilities and Exploits - https://cve.mitre.org/. There are various aggregators of these. For *nix exploits, various distros will have bugs that (mostly) map to CVEs - e.g. Debian has DSAs.
From the site: "CVE is sponsored by US-CERT in the office of Cybersecurity and Communications at the U.S. Department of Homeland Security."
Serious question: How worried should I be that my defacto, go-to database of software vulnerabilities is paid for by the United States Government? How independently run is it? Need I fret that vulnerabilities won't be publicized if they benefit government agencies?
Serious question: How worried should I be that my defacto, go-to database of software vulnerabilities is paid for by the United States Government? How independently run is it? Need I fret that vulnerabilities won't be publicized if they benefit government agencies?
One of the more common (and more visible) ways CVEs are assigned is by asking for one on a public mailing list operated out of Russia.
They're not the gatekeepers of anything. Even if they didn't accept something, you could still post to http://seclists.org/fulldisclosure and everyone who cares would know about it. So there's no reason for them to hide/refuse any entries.
The culture of different government agencies varies widely. US-CERT is run by Carnegie Mellon University. US-CERT, incidentally is far older than the relatively new DHS. US-CERT, Mitre, and the rest are all about transparency and don't have motivation to hold onto really effective exploits.
However, if NSA discovers a ground-breaking exploit, and it's deemed low-risk to US systems, they'll probably keep it. But they certainly wouldn't disclose it to US-CERT or Mitre. Not to mention, since US-CERT and Mitre aren't in the intelligence community, they don't have a mechanism to keep information like that undisclosed.
However, if NSA discovers a ground-breaking exploit, and it's deemed low-risk to US systems, they'll probably keep it. But they certainly wouldn't disclose it to US-CERT or Mitre. Not to mention, since US-CERT and Mitre aren't in the intelligence community, they don't have a mechanism to keep information like that undisclosed.
It was 11 months from discovery to public disclosure, interesting.
I wouldn't have thought it possible to generate a negative-sized request...
One of my pet peeves is fixed-length buffers in C code, of some size that (thankfully, it's checked to prevent going off the end - most of the time, at least...) has no real justification documented anywhere - "why use 72 bytes and not e.g. 80? Why 999, and not 1000 or 1024?" If you're going to use C, I think you should be paying more attention to memory allocation and how big things like requests/responses can be; otherwise, you should use a "safer" language possibly with dynamic allocation that can handle any size... but on a constrained system like a router that may not be possible (or it'll just turn into an opportunity for OOM DoS.)