Fork me on GitHub

I think that org.clojure/data.priority-map is being erroneously flagged with CVEs: CVE-2022-23173, CVE-2022-23172


Lein NVD reported them on version 1.1.0, and another tool (unknown, used by a client) has flagged them.


if you look at CVEs they seem to be talking about something else entirely


yeah this came up at work:


this vulnerability affect user that even not allowed to access via the web interface. First of all, the attacker needs to access the "Login menu - demo site" then he can see in this menu all the functionality of the application. If the attacker will try to click on one of the links, he will get an answer that he is not authorized because he needs to log in with credentials. after he performed log in to the system there are some functionalities that the specific user is not allowed to perform because he was configured with low privileges however all the attacker need to do in order to achieve his goals is to change the value of the prog step parameter from 0 to 1 or more and then the attacker could access to some of the functionality the web application that he couldn't perform it before the parameter changed.


An attacker can access to "Forgot my password" button, as soon as he puts users is valid in the system, the system would issue a message that a password reset email had been sent to user. This way you can verify which users are in the system and which are not.

👍 1
Alex Miller (Clojure team)20:08:02

it is and I filed a false positive report on it

Alex Miller (Clojure team)20:08:40

as you can see, getting this fixed can take a while. have done this in the past on something else and it did eventually get cleared up

Alex Miller (Clojure team)20:08:02

but feel free to +1 the issue to raise visibility :)


thank you so much @alexmiller. didn’t know where to report to as we had a customer send this to us. I’ve shared with out engineering org to hopefully get lots of thumbs flying.

👍 1

:thumbsup::skin-tone-2: Since we also ran into this at work.


FWIW @alexmiller I see CVE-2021-43148 for org.clojure/core.async 1.5.648 which also seems like a false positive?


I find nvd useful but it does seem to report quite a few false positives.

Alex Miller (Clojure team)01:08:08

I think the "matching" they do seems much less precise than it seems like it could be


It feels that way to me too. I am very thankful for the tool, but reporting so many false positives might make users more inclined to accidentally ignore real security issues.

Alex Miller (Clojure team)02:08:33

at the moment it seems like the problem is users assuming that false positives don't exist


yeah, that too.


We have only 4 CVEs reported at work now -- we've worked hard to get rid of a lot of them -- and 2 are the FPs mentioned above. I think both of the others don't yet have (compatible) updated library versions to address the CVEs.


We need to take the time to bump ring to jetty 11. Jetty 9 has some issues


In any case, false positives can be ignored locally (`suppression-file` so they're never a blocker Also, lein-nvd doesn't exist anymore (it's been renamed to nvd-clojure) and it is very strongly recommended that you don't use the Lein plugin


Lastly, by keeing nvd-clojure up to date you'll keep up with the effort done at at zapping false positives - they actively improve them with every release


Heya @U45T93RA6, thanks for all your hard work on! Much appreciated!

🍻 1

Update: it seems that the FP on core.async is no longer being reported (so yay! for that) but the data.priority-map FP is still being reported. Does NVD know about that one? I think I remember @alexmiller saying he'd filed at ticket to get core.async unlisted?


Turns out it was for data.priority-map and that does at least provide the suppression XML so I can use that locally to stop NVD whining 🙂


The suppression format isn't too contrived, you can always resort to it :)


@U45T93RA6 Figuring out exactly which variant of the XML would work to suppress the FP on data.priority-map was a pain -- I tried <cve> and <vulnerabilityName> and neither worked. Figuring out exactly how to set the files up as configuration was non-trivial too (rather than using command-line arguments). I posted exactly how I did it in the end in #C02Q6253MPZ -- finding the <cpe> variant was the right one, via that GH issue was key -- and without generating the HTML report that format would have been very hard to deduce.


From memory, all the variants I've used worked. There isn't a reason why things would randomly not work. Maybe you were one tweak away from success? You can always create an issue showing a specific case or requesting a specific doc improvement.


I suggested -- in the #C02Q6253MPZ channel -- that an example of dependency check suppression be added to the README of clj-watson 🙂


alright, it wasn't clear in the prev post if you were talking about past experiences with nvd-clojure


How many times do I have to say "I stopped using nvd-clojure and switched to clj-watson" before you stop butting in with smug comments? 🙂

👎 1

In this case, the only difference between the working XML and the non-working XML that I tried was switching the <cpe> entry (which I found in the ticket) for <cve> or <vulnerabilityName> which are in the DependencyCheck docs and implied to be equivalent if you have the CVE-... string.


Unfortunately the main issue with these CVE false flags I have is not when I use detectors, there I can ignore those few false positives I know, but when my clients use some unknown CVE detector on our JAR, then complain to us about CVEs.


For whatever reason, those don't work in this case and I have to use the <cpe> form :man-shrugging::skin-tone-2:


I literally didn't understand what you wrote in;cid=C03S1KBA2 and was wondering if it could be useful to improve nvd-clojure, that's all 🤷


@U66G3SGP5 True. This is only for our internal auditing but I've seen external pressure due to false positives. At least core.async is no longer reported incorrectly. Hopefully that GH issue about data.priority-map will get addressed soon too.

Dustin Getz23:08:52

Can i please get a code review on this datafy/nav attempt for directory traversals

Dustin Getz23:08:23

Specifically around the lazy file listing using ... and also I think the file attributes should also be lazy?

Alex Miller (Clojure team)00:08:56

in line 55, datafy will be called on the result of nav iirc, so you should just return a File there

Alex Miller (Clojure team)00:08:38

we have an impl of this inside rebl so I'm trying to eyeball any differences (the datafy fields are all different of course, but it's similar)

Alex Miller (Clojure team)00:08:26

rebl lets you nav into (some) file contents too (based on extension and size)

Dustin Getz00:08:58

Thank you – who is responsible for calling datafy on the result of nav? You mean in the context of REBL use case?

Alex Miller (Clojure team)00:08:21

in the context of proper use of nav

👍 1
Dustin Getz00:08:24

thx appreciate it

Alex Miller (Clojure team)00:08:32

as you can see by the extensive documentation on datafy and nav


Update: it seems that the FP on core.async is no longer being reported (so yay! for that) but the data.priority-map FP is still being reported. Does NVD know about that one? I think I remember @alexmiller saying he'd filed at ticket to get core.async unlisted?