Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2022-33085PUBLISHED: 2022-06-30ESPCMS P8 was discovered to contain an authenticated remote code execution (RCE) vulnerability via the fetch_filename function at \espcms_public\espcms_templates\ESPCMS_Templates.
CVE-2022-33087PUBLISHED: 2022-06-30A stack overflow in the function DM_ In fillobjbystr() of TP-Link Archer C50&A5(US)_V5_200407 allows attackers to cause a Denial of Service (DoS) via a crafted HTTP request.
CVE-2022-31115PUBLISHED: 2022-06-30
opensearch-ruby is a community-driven, open source fork of elasticsearch-ruby. In versions prior to 2.0.1 the ruby `YAML.load` function was used instead of `YAML.safe_load`. As a result opensearch-ruby 2.0.0 and prior can lead to unsafe deserialization using YAML.load if the response is of type YAML...
CVE-2022-33082PUBLISHED: 2022-06-30An issue in the AST parser (ast/compile.go) of Open Policy Agent v0.10.2 allows attackers to cause a Denial of Service (DoS) via a crafted input.
CVE-2013-5683PUBLISHED: 2022-06-30** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was in a CNA pool that was not assigned to any issues during 2013. Notes: none.
User Rank: Apprentice
3/3/2016 | 8:22:58 AM
This bug was in an extraneous feature, I don't want an AV that runs its own webserver on my host. Our advice is choose an AV that doesn't do silly stuff like that. So lets assume we can disable all those extra features, now we're left with this big chunk of C/C++ that tries to parse every file type you've never heard of that regulation says we have to keep on our hosts. Ok, if I can't get rid of it I can at least make attacking it more expensive for common bug types in C/C++ with Microsoft's EMET. Though as we've seen recently thanks to FireEye there are ways around that for dedicated attackers but attackers have to spend a lot of time to find those. How do we then deal with an attacker who is willing to do that leg work? We monitor our hosts for surprising new binaries/DLLs as attackers typically want some type of persistence.
In following that advice we have: reduced our attack surface by turning off AV features we don't need, increased the cost to attackers to attack us via bugs in the core part of the AV engine, and increased the odds that if we are successfully compromised we'll know about it. That's pretty reasonable substantive advice for how to deal with vulnerabilities in your defensive tool chain. I hope that readers don't come away with the impression that all security software is bad, I hope they come away with the idea that NO complex software is without vulnerabilities and they need to plan accordingly.