I think this goes hand-in-hand with people naming security vulnerabilities and trying to make it a big spectacle. Sometimes it is a legit serious vulnerability, like shellshock or heartbleed, but a lot are just novices trying to get their 15 minutes of fame. I remember a few years back there was a "vulnerability" named GRINCH, where the person who discovered it claimed it was a root priviledge escalation that worked on all versions of Red Hat and CentOS. They made a website and everything for it, and tried to hype it up before disclosing what it was. Turns out the "vulnerability" was members of the wheel group being able to use sudo to run commands as root.
CVE Stuffing
21–30 of 108 posts
Re: CVE Stuffing
#22[deleted]
Re: CVE Stuffing
#23I'm a command-line development tools maintainer for an OS. I am not unfamiliar with high-level CVEs in my inbox with the likes of "gdb crashes on a handcrafted core file causing a DoS". I am unfamiliar with a real world in which a simple old-fashioned segfault in a crash analysis tool is truly a denial of service security vulnerability, but our security department assures us we need to drop all revenue work and rush…
Maybe you can get on the phone with your customers, their security teams, and their compliance teams and explain every single day why these known vulnerabilities are not serious and can never be leveraged. You can convince them all of these latent bugs will never pose a serious risk. You can do this all day every day. Or you can just patch, and maintain a capability to do so quickly because bugs don't just affect sec…
> really a reflection of awful development practices.
You don't know a thing about GP's development practices so perhaps you should be a bit slower to hurl accusations.
Re: CVE Stuffing
#24That sucks. Perhaps the most annoying part of modern infosec is the absolute deluge of noise you get from scanning tools. Superfluous CVEs like this contribute to the sea of red security engineers wake up to when they look at their dashboards. Unsurprisingly, these are eventually mostly ignored. Every large security organization requires scanning tooling like Coalfire, Checkmarx, Fortify and Nessus, but I've rarely s…
We use Nessus and it's not too bad on the false positive front. I usually check the scan results every week or two to see if it finds anything new, and I know our Head of IT also keeps an eye on them. In an ideal world we'd automate this away but have a raft of more pressing priorities.
We also use tools like Dependabot to keep an eye out for vulnerabilities in our dependencies, and update them to patched versions. This is genuinely useful and a worthwhile timesaver on more complex projects.
It's easy to be cynical about automated scanning (and pen-testing for that matter) and, although it's often needed as a checkbox for certification, it can certainly add value to your development process.
Re: CVE Stuffing
#25That sucks. Perhaps the most annoying part of modern infosec is the absolute deluge of noise you get from scanning tools. Superfluous CVEs like this contribute to the sea of red security engineers wake up to when they look at their dashboards. Unsurprisingly, these are eventually mostly ignored. Every large security organization requires scanning tooling like Coalfire, Checkmarx, Fortify and Nessus, but I've rarely s…
> The current state of CVEs and CVE scanning is that you'll have to wrangle with bullshit security reports if you run any nontrivial software. Especially if you have customers who outsourced their infosec to the lowest bidder who insist every BS CVE is critical and must be fixed.
This ^^^. I have experienced it first hand for the last year or so, and it gets really annoying!
Re: CVE Stuffing
#26Way back when I saw a report on hackernews about secret exposure from websites that deployed directly via a git repo as a webroot and didn't block access to .git/ I added a cheeky message to my site's .git/ folder if you attempted to view it. About 2 or 3 months later I started getting "security reports" to the catch all, about an exposed git folder that was leaking my website's secrets. Apparently because my site di…
> Apparently because my site didn't return 404, their script assumed i was exposed and they oh so helpfully reported it to me.
There's no good reason that folder should exist except for a joke, so how is this not a helpful message in the vast majority of cases? All lint rules have exceptions, doesn't make them not useful.
Re: CVE Stuffing
#27Communication breakdown.
It's a bit naughty how "security researchers" don't appear to make a good effort to communicate upstream.
And the fact that Jerry has problems reaching out to NVD or Mitre is worrying.
Re: CVE Stuffing
#28Way back when I saw a report on hackernews about secret exposure from websites that deployed directly via a git repo as a webroot and didn't block access to .git/ I added a cheeky message to my site's .git/ folder if you attempted to view it. About 2 or 3 months later I started getting "security reports" to the catch all, about an exposed git folder that was leaking my website's secrets. Apparently because my site di…
Speaking of "security exploits" consisting of reading publicly available information: Tarsnap has public mailing lists with public mailing list archives, and at least once a month I get an email warning me that my "internal emails" are accessible.
Re: CVE Stuffing
#29Didn't check who filled those bugs, but I've seen companies requiring having discovered CVE to apply for some jobs, and the natural consequence is gaming the system...
[deleted]
Re: CVE Stuffing
#30That sucks. Perhaps the most annoying part of modern infosec is the absolute deluge of noise you get from scanning tools. Superfluous CVEs like this contribute to the sea of red security engineers wake up to when they look at their dashboards. Unsurprisingly, these are eventually mostly ignored. Every large security organization requires scanning tooling like Coalfire, Checkmarx, Fortify and Nessus, but I've rarely s…
The non stop stream of emails every day certainly sucks but falls far short of my employers false positive process which requires several emails explaining why it’s false positive and following up to make sure the waiver is applied so as to not impact our security rating instead of just reassigning the jira ticket and adding false positive label.