Fork me on GitHub
#clojure
<
2021-12-12
>
Ivan Fedorov11:12:30

Is anyone aware of any dependency / source scanners that would detect usage of JNDI, JNI and other potentially privilege-escalating APIs?

3
h0bbit20:12:45

I'm not sure if nvd is soomething you are looking for? https://github.com/rm-hull/nvd-clojure

❤️ 1
Ivan Fedorov21:12:06

That’s awesome! Thanks a lot @h0bbit!

h0bbit21:12:56

Do note my message a later in the channel though. nvd led me down a wild goose chase that caused me to lose a few hours on the log4j exploit. I guess I should have double-checked earlier, but now I've learnt an important lesson about how nvd works :P

vemv22:12:46

nvd can be a bit 'traumatic' to adopt for the first time :) especially for large projects. once a project is on the right track, subsequent fixes should be an easy chore.

h0bbit04:12:43

ack @U45T93RA6 . It's definitely super cool and something I will be using regularly going forward.

h0bbit20:12:40

So we're on the horrible journey of updating log4j. Unfortunately, we are on log4j 1 (1.2.17 to be exact) and are moving to log4j2 (2.15.0). The upgrade is fairly straightforward, since ctl is hiding most of the logging complexity, but the problem is this: there is no replacement for the function getCurrentLoggers (no way to directly manipulate loggers in log4j2). This is a problem because we have a huge number of tests and a handy function that turns off logging when running tests to avoid printing tons of log-lines. Does anyone here have pointers about how to stop loggers from initializing in test runs?

dpsutton20:12:56

We set the logging level to fatal for tests. You can check out the Metabase repo on GitHub for how we achieve this

h0bbit20:12:07

thanks, checking

h0bbit20:12:22

thanks @dpsutton . Just to summarize for everyone here, log4j2-test.xml has higher priority than log4j2.xml , so the way to achieve this is to add a folder to your test profile which contains such a file.

seancorfield20:12:20

We do the same (set level to fatal during testing) but I think we also have some code that scours through the APIs getting every single logger as well. If you still need such a thing, ping me and I'll dig it out of our codebase.

potetm20:12:47

@h0bbit I dunno if this is in regards to shell4j, but I thought log4j 1.x was unaffected and that 2.15.0 was included in the affected versions: https://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228/

potetm20:12:30

2.15.0 is the fix

h0bbit21:12:00

Yes, 2.15.0 is the fix. You are right about Log4J1 not being susceptible @potetm . I'd initially inferred just that but then got swept up in the hype when https://github.com/rm-hull/nvd-clojure told me that 1.2.17 was vulnerable. :( https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes/commit/74fe323cba30829c57661d1dcbad1126c208ee72 + http://slf4j.org/log4shell.html confirm that 1.x is not vulnerable

seancorfield21:12:19

Yeah, log4j 1.x isn't vulnerable to this exploit but it's got its own problems and it ain't getting any updates or fixes at this point so it's something to get away from if possible.

seancorfield21:12:54

(and I believe, from reading too much on this topic, that if you have log4j 1.x with a JMS appender, you can still be vulnerable -- but I don't know how common that configuration is)

seancorfield21:12:18

☝️:skin-tone-2: @potetm

👍 2
h0bbit04:12:07

Yup, I might as well take the effort I've put into it and complete the migration anyway :)

Ivan Fedorov21:12:28

Sharing my notes on the subject, there’s a section on Clojure Additions, corrections, critique – welcome https://lightpad.ai/w/blog/500625400

seancorfield21:12:49

You should probably mention nvd-clojure

Ivan Fedorov22:12:47

I mentioned it, but will highlight, thanks!

seancorfield22:12:11

Ah, I missed it because you talk in the last paragraph about automated scanners as if we don't have any -- but I see you mention them very briefly just above that.

seancorfield22:12:38

As for scanning requests for the strings -- I saw that they're already obfuscating those as much as they can (so that jndi is no longer visible as a string). Sneaky lot.

h0bbit18:12:28

Nice post @ognivo. In a similar vein, I've published a dummy project to correctly use Log4J2 as the logging backend for Clojure projects. This has been mostly for my own understanding, I'd love it if interested folks can review it and suggest improvements: https://github.com/vedang/clj-logging

💯 3
bg05:12:52

@h0bbit could you please explain the use for lmax disruptor? is that necessary?

h0bbit05:12:10

@U0505RKEL : Adding the disruptor dep allows you to use "async logging" (bufferedIO=true in the log4j2 config files + a JVM option for asynccontext). This is much faster (~30% faster) than sync logging into a file with very acceptable tradeoffs and no other change required. It isn't necessary for normal sync logging. More information here: https://logging.apache.org/log4j/2.x/manual/async.html

bg05:12:16

Thanks @h0bbit this was insightful!

Ivan Fedorov14:12:48

@h0bbit thanks a lot! added to the post

h0bbit18:12:28

Nice post @ognivo. In a similar vein, I've published a dummy project to correctly use Log4J2 as the logging backend for Clojure projects. This has been mostly for my own understanding, I'd love it if interested folks can review it and suggest improvements: https://github.com/vedang/clj-logging

💯 3