On The Many Habitats, Hiding Places, and Known Camouflages of Apache Log4J - Julius Musseau

okay hello um i'm sharing the whole screen so we'll just have uh infinite screens for a moment sorry about that although i kind of like it it's pretty right okay we're live um is there anyone here i wonder how i find out if there's anyone here okay here we go hi ashley yes yes exactly waving to myself infinite screens and soon we will see infinite log4js so yeah this talk is on the many uh shapes are not shapes but the many hiding places well kind of shapes actually shapes as a good uh a metaphor as well for uh for log for day the habitats hiding places camouflages log4j and uh it's gonna be kind of a live coding

session um and just to confirm i believe we have um you know uh 50 minutes remaining right this does this one go till 3 p.m

and yeah okay that's a good thing to know okay um so let's get started with log4j i'm gonna get myself bring up a terminal here and get a log for today so um the the goal here is really to educate everyone about you know like jar files right i have a unnatural passion for jar files when i was a a teaching assistant at ubc i was working on a phd sadly had to drop out of that phd you know life happened life got a lot more complicated than a phd so i had to drop out this was back in uh 2013 but i was so i was my passion for jar files is over 10 years old

and um let's get a session let's get a terminal term and all you guys are in there i'm not re i'm a linux person i've only i'm only dean to go on a terminal here for this talk here because uh you know web conference software doesn't usually work on linux or you usually can't share screen on linux so i'm i'm in a foreign land here with uh being on on a mac so everything will be painful for me forgive me are you guys the same size you guys are the same size let's have three of you um okay and let's go jump to the other machine and what is that machine

you are oh what my other machine has a naughty ip address today oh no oh well that was not on purpose this is where all my good log freaking examples are is on that machine so anyway yeah so like i was saying back in my ubc uh days when i started that phd um yeah one of the my students actually at the end of the semester he gave me a jar file not a file a jar an actual jar just a glass jar at the end of the semester he says you are so passionate about jar files i just i had to get you this and so i still have this jar in my in my cupboard

um so jar files for those that aren't familiar are this how you um store uh how you put together how you distribute java code okay just like you know dlls are often how you distribute uh c plus plus or or c sharp uh that's being developed on windows well jar files are how you distribute java code and i'm actually passionate about all um distribution formats for software i'm passionate about gem files that's ruby i'm passionate about um you know npm files of course that's uh the javascript uh dlls um go modules all of them but java was my first language and so i have a special love for jar files and and and log for j of course comes down as a jar

so don't uh you don't tell the other languages um that i feel that way about java please i don't want them to feel bad anyway moving on here to log for j the problem with log for j or the problem with any really any distributable piece of code any you know compiled artifact i know technically java is not compiled but i mean what i mean is like any that's thing you know box container oh can't use that word anymore any um just packaging you know mojo component library all of these things the way that we compartmentalize software such that we can refer it to as a thing like oh the log for jr any of those

right um they kind of like when a known vulnerability drops like the huge lock for jcve cve 2021 uh what was it four four two two eight right um that cbe says oh if you have log for j if you have this version of blog for j you need to not have that version of vlog4j you need to have a different version of blog4j otherwise you're going to get you know exploited severely it was an amazing amazing cbe one of my favorite cbes in the last five years in the last five years i have two favorite cvds and this one definitely was one of them so but this this problem is right is like if you have log4j this

version of vlog4j you need to not have that version you need to not be running that because in that version of blog4j is the bad code the bad code that can be compelled tricked into you know giving away the keys to the kingdom so um there's suddenly there becomes like this almost epistemological problem when i say log4j 2.16.0 what do i mean right so let's start there um i think i'm going to direct you here so if i say log for j oh you silly mac sorry i'm gonna be grumpy about being on a mac this whole time because i have no idea how to use them there's frame iron oh infinite windows again um seen any any we've got private chats

oh i can't share their private chats that's bad i did though yes um [Music] yeah there's a log for jay deep down there somewhere so initially when we say log for j2.16 i think it's dot oh right do we mean this guy this by the way this is uh repo one.maven.org and when developers build java projects like with their you know if you're if you've got all the java tool chain and all the uh compilers and intellij and eclipse and all that good stuff like if you're making a java application um by default this is where you're gonna get your libraries from repo one.maven.org it's actually hosted and maintained by sonatype and so sonotype they compete with my company

mergebase and so i'm always very bitter that they get to host this because they get to call companies up and they'll be like huh did you know um hi there vmware we just want to let you know you guys downloaded this bad version of log4j uh 82 000 times in the last week just thought maybe you might want to give us a call so you know because we don't host repo1.maven.org we don't have data like that we can't call up a company and say i mean i guess we could but we'd just be making things up we wouldn't have empirical data like sonatech does yeah this is actually hosted by sonotype sometimes an interesting company right because

um it was the whole maven team the team that invented and made maven which is a critical tool in the java world for building software uh at apache they uh they formed a startup and sonotype was their startup they they launched that startup like probably 17 years ago anyway so when i say log for j2.16.0 do i mean this one right in here let's bring it down and voila so now i have vlog and in this log for day is the bad code right that causes the the the terrible vulnerability um for those i mean i figure probably everyone here today uh is familiar with that vulnerability but just in case you aren't uh just in case there's the one i mean

because i'm sure i have like a thousand people in the audience today right very popular talk and so there's probably like one out of those thousand people that hasn't heard of the log fragic vulnerability and um so the deal with the log4j vulnerability is log4j is as a logging framework and it goes back to actually 1999 i was looking at the source code of it it was a proprietary private piece of code developed in 1998 1999 and then it was donated to the apache software foundation in i think around 2002 and yeah it was like it was a revelation it's a beautiful beautiful logging framework beautiful piece of software like for those that had been trying to do application logs

in 2001 with java including me um you know you just would do horrible hacky things and then log fridge came and it just showed you this beautiful way to just uh leverage this natural structure of java programs to to um to do your application logging and just in a beautiful natural way and so since log4j like actually goes back all the way to 2002 it's it's in everything and and it was such a beautiful library with such a beautiful mechanism for doing logging um that you know it really is pervasive it you know like you write a good library like a library this guy i can only dream to write a library this good um

it's gonna be everywhere so with it being everywhere um now here comes this problem is that they had this cute little feature that they um that they brought into the product around 2012 i believe um i could be wrong about that but sometime in the last 10 years they brought in this cute um feature to help make logging even more convenient for you know application developers of this uh substitution uh this uh this key value lookup mechanism but the problem with this this um this lookup mechanism was that um any log message that came into log4j to be sent to disk um to be logged into a log file and disk would could take advantage of this

substitution method any log message could like they just accidentally um didn't realize that i think the moment the developer saw that this was possible that any substitution anywhere it was originally the substitution logic was actually for the config files but then because it was so convenient it got uh ported over to the main logging uh infrastructure but then because it was um i think the developers just just didn't quite realize oh this this look up this neat look up substitution routine is available to anyone writing along so if anyone can control the log message any aspect of the log message they could trigger this lookup routine and then the lookup routines there was like a whole bunch of them you could do

jndi lookups ldap lookups you could even like go to some code repository and download bytecode you have a bytecode on the fly if you coded the substitution lookups carefully right based on jndi and so essentially anyone that could have any control over the logging message could cause you know remote code execution and so you had this funny situation on minecraft servers where log4j was logging all messages in the client minecraft actually um very popular versions of minecraft are were written in java continue to be written in java on the server and in the client i think the pc version i think on the iphone it's not in java but i think in the on the pc version

it is in java and of course it needs application logging and it was logging all chats so if a player was chatting with other players log4j would be the the software that was actually handling that oh someone well not handling the chat but logging all the chats and so um this situation was happening where one player could use the exploit to take over every other player's computer and the server's computer right uh this rc was so hilarious in that regard because they control the chat message that they're sending and since the chat message gets logged to disk and they have full control over what they chat to the other players they could just type in the x-play

so that was amusing so this is a severe severe bug and so now you get to this problem of you know is log4j 216.0 in my system so um normally i would ask the audience so how would you do it how would you find out if log4j 2.16 the volume related itself actually goes back to like pretty much the whole 2.x branch up to 2.16 log for j1.x uh very uh different uh implementation 2.0 was a complete rewrite and so this vulnerability because 2.0 it said 2.x is a complete rewrite the vulnerability is only the 2.x series if you were on long for j1.x you got other vulnerabilities to worry about but nothing quite as bad as this one so

anyway yeah let's do we have log4j2.16.0 or earlier how would you how would you find that on your system let's infinite mirror each other to see if anyone has any ideas

um so far no idea so if you have an idea how would you find log4j 2.16 on you on your system give you guys 10 more seconds if anyone has an idea

okay um one popular idea was to you know just take the the of log criteria itself right like so you could just take a sha-1 or md5 like you know people can say that md5 is insecure but for this kind of situation where you're just trying to identify is a file on your disk it's it's totally reasonable um so if you see this hash anywhere on your file system including um you know uh a zip inside a zip inside a zip right you can just you know recursively descend into the zip files and just scan every file inside of them if you see this then yeah definitely that's a bad situation the the problem though is that uh the

jar files are actually zip files and zip files are actually fairly resilient against um um you know just like bite changes to them and um like for example i can just like append a space to the to the zip file and it's still a completely valid zip file it's still gonna work completely fine it's got no problems see i can get a listing of it i can unzip it um right so it's totally fine it's not complaining of uh you know any problems at all but i added a space to it so it's gonna have a completely different shaw once i'm so i mean that's not really uh a way that you um that the jar files are

getting changed people aren't normally adding spaces to them but um my point right it's just like like um we're not so much worried that the jar falls on this what we're worried about i'm sorry you you go away you're making it hard for me to see are we still sharing though oh yeah oh so i just go there hide and then you come back okay cool

yeah my like my point right is that um the um what we're concerned about right is that the logic right it's the logic that causes the um it causes the bug right it's not the uh the file itself that causes the bug and um sure enough right like let's go let's go um build some class files like let's let's um and other factors right like um for example the zip files themselves have date stamps right so if i were to build log4j core um and so i have a little example that i'll use let's go get the log4j detector that i built

okay

i'm going here and we're gonna go let's enter what i'm just gonna show you it's um for example we'll start with by just building it so i'm gonna build it right now

um my point here is about jar files so now i've got lock for j detector latest and so let's put that here larger j detector latest uh i'll call it old because i built it and let's rebuild it build it again and then let's call this one new right so the exact same code old and new and it's um you know exact same bite count et cetera but is it going to have the same shaw and son pretend it was this is the actual log4j library itself i just want to show you something about using sha ones or you know any byte oriented signature to detect log for j just have to remember how to

control paste here okay do something exciting there so if i uh there's the one we just did and there's the one i did seconds ago right why do they have such different um shot one so this is not going to work right detecting based on sha 1 is not gonna work because i just built the exact same code uh minutes apart and they're having different sha ones i'm sure half the people if not more on on this on the call here uh know the answer but i will tell you anyway and the reason see if you can spot the difference that's the new one and so i'm just doing a listing on it right

so you are old and you are new 88203 2727 26 27. well 1375 1375. looks like i don't even know why they're different um did perhaps the poem about properties because they did a maybe maybe install it yeah yeah yeah so that's new i mean with the time stamps i'm curious like the time times don't look oh yeah yeah because that's 227 it's the seconds that changed um on them and i'm just not seeing the seconds in this listing that's right so i should have waited like a minute before doing builds and then we would have seen the minute changed i guess we could do that now because it's probably been a minute

so i built it again and you are you can be new

yeah so you can see it's using for 230 as the timestamp now whereas before it was using 227 as the timestamp well those time temps are part of the byte stream and so because the timestamp the build time of the jar file itself is is is changing based on the time that we build it then that's going to cause the the sha one to change right so that's why that's one of the reasons why a finger based um approach is is not going to work right like it's true the nice thing about the fingerprint based approach is you know probably 95 percent of log4j2.16.0s in the world are gonna just come from maven central people don't

rebuild log4j normally normally they just download it from here and copy it into their system and off it goes i guess but my point is that you know this bug is so severe that the fact that 95 percent of the time the driver will actually be bite for bite identical as this one here on maven central uh is not good enough right like that that five percent chance and that's just my gut saying that um that you might not have the bite for bite identical version here like maybe you're running artifactory in-house and maybe your artifactory resigns the jar files um that's i've seen that pattern where people set up signing keys on their internal artifactory

um and so artifactory is going to be resigning all the jar files before it lets your internal systems bring them into its uh into its build right well that's going to again that's going to perturb the key so right so if you do a scan looking for this xiao on fingerprint again you're going to miss it you're going to miss all the log projects or if you guys if you have a policy like you know gen 2 is a famous linux distribution of having a policy of of rebuilding the operating system from scratch right well not from scratch but every new package that you bring down is going to get recompiled before it's installed in your gen 2 right so

if you take a if you were to run a similar philosophy with your own java application that means you're going to download and recompile log4j every time you do a build right like that's not an unreasonable uh um you know best i wouldn't call it a best practice but it's it's not an unreasonable practice uh when building software to be like okay all my dependencies they better build and i better build them myself right well again this uh a fingerprint based approach is not gonna work so what do we got to do if a fingerprint of the jar file is not good enough see if any comments here okay tim good to see you tim

um run black duck yeah definitely i'm curious to just know how black duck will do if it can find it in all its variations you could unzip the war files okay so let's unzip you could just look for every jar file that has the word log in it too well okay more problems there

let us evaluate all of those ideas and by the way thank you for the um the comments i'm i'm i really appreciate the comments that makes this more fun for me um so the first one is run black duck i don't have a black deck license so i can't do that probably that would work well i am very curious to know i actually have a whole corpus of um log4j samples i think i called it log4j samples so um if anyone has yeah if anyone has a blackduck license um if they would like to take this corpus so it has all these different versions of blog4j done as uber jars done as uh shaded jars

done as spring boot executable jars right etcetera done as exploded jars so if you have a black deck license i would be very curious like if you were to take my log4j samples repository and um and clone it and then um

and then run black back against it i would be very grateful that is i'm sorry i just don't know how to use mac plus okay mu i'm just gonna use the mouse yeah we can do the mouse the mouse can do this yes and this is a public repository anyone's free to clone it and down come all these nice variations of log4j and so use the log4j samples repository to test your scanners see what your scanners think

and we've got the false hits whoops uh you got the false hits so these ones um

yeah do not have the bad vulnerability oh yeah yeah that's right 216 actually was patched later it's a 2.14 that has it um there was some follow-up vulnerability so they quickly the team quickly brought out 2.17.1 so these are all the versions of block feature that don't have the vulnerability including api and slf4j and old log for j 1.x and exploded right and then the true hits so just take your um so these are all versions of log4j that have the vulnerability in various uh incarnations these are just downloaded from ravencentral but then i explode them i shade them i do springboot executable of them i uber jar them these are different ways that people package up java and

distribute it and then uh and then finally oh yeah old it's log for j1.x right see what your scanner thinks of that so yeah regarding blackbook i would love to know if anyone's got a black click license please run it against this public repository log4jsamples on github and and let me know i'd be very grateful now as for unzipping the war files if we just unzip every war file then the jar files will be in there right um and or unzip the jar files themselves right because if it's just a date stamp

for problem this one that i was building if it's just that if it's just a bait stamp problem what you could do is um forget about the date stamps right so this is a cool idea and i'm actually going to go somewhere else to do this idea here hey because and i'm going to take a copy of that okay let's use you can be java eight and you can be each eleven and you can be joe i think i got number 17 and you can do java six sure

so what i'm gonna do one six hopefully it works i don't know if java 6 even works on this computer anymore

and it's done we built the class files right so my example what i'm trying to show here is that even compiler variation unfortunately will perturb the signatures so that's java 6. let's do java 8. um

oh which java 8 should i go with i mean the thing is you want usually you won't see um oh yeah sorry i don't have a file called a okay so which one should we just use for maybe util that class looks kind of interesting so i'm going to do a shot on some on util.class and then let's do the same in our log between our java 6.

and lo and behold right exact same source code but i used java 6 as a compiler versus java 8 in the compiler and oh no the um the bytes have changed so unfortunately that means um taking signatures of the underlying um like taking bite signatures like sha-1 signatures of the fingerprints of the underlying class files is not going to work either because compiler variation is going to trip it up i'll even go i mean of course um compiler variation like um i'm like back in the day here um first if i go like you know like that you know optimization level of course that's gonna um have changed it as well how do you do that how do i do

optimization level and debug symbols of course so if i do yeah debugging info that's like you know there's all these different ways that you can um perturb the byte code as you're compiling i can't remember how to set the optimization level on in the compiling um but even just the version yeah as i've showed java 6 java 8. i could keep doing it i you know i could go to java um 17 java 11 but i think you guys believe me that every one of those is going to have different signatures so unfortunately um unzipping them all and looking at the underlying fingerprints of the actual class files which contain the logic of the vulnerability that's not going to

work either it's not going to you know it's not going to be bulletproof and the goal here is we want something bulletproof like this is a severe vulnerability um we don't want to have any any chance that uh that that vulnerable version is on disk

yeah and then yeah looking for looking for all files with log in the name it's a it's a very good fast approach um but again i mean you can even see with the samples here

with the true hits

it's it's not these are all true hits eh so this like um this jar war zip ear and this zip file and this funnel jar right like they all uh have the vulnerable version of blog4j in them and so for example in the uber unfortunately looking for log yeah it's not going to find it in that case ubercards are very interesting i've actually i've written a blog post about them um encourage you guys to go look at that uh uber jars um where would you i guess you just put merge basement company or julius you just go uber drives jewelers and then i think you get it yeah software composition analysis versus uber jars right

so they're a funny way that java gets distributed that is actually not that uncommon for example um does anyone here use jira or bitbucket or confluence and if you use those products bitbucket or jira or compliments on-prem the on-prem versions of those products um you probably use the plug-ins right where you go to the plug-ins to say oh i'll take this you know i can draw charts in my jira tickets if i take this plug-in or this another plug-in that helps me do timesheets in my jira and this plug-in helps me like draw sequence diagrams in directly on the glass and confluence right well those plug-ins they tend to be built using this uber um

approach that's just how atlassian java plug-ins all atlassian plug-ins for confluence here and pipbucket are java because atlassian those are java project products and the plug-ins themselves are put together using this uber technique right and so you might have an atlassian jira plug-in using log4j and so you're going to need a technique that can you know deal with this this situation if you want to make sure that you know all your desks in your corporation don't have log for day so good little uh blog article on this in this problem so i mean so far i've i've shown you all the that the fingerprint based approaches just aren't going to work here um what will work however

is to look and this is what i ended up doing when i i made a log4j detector um let's just run it find fun to run

a detector so when i made this log project detector um let's use the latest

the goal is to look at everything on disk to any recursion level right no matter how things were put together um including shaded shaded is wild because that's where the log4j code is actually renamed all the class names are renamed to different class names to avoid class path conflicts and so i'm looking at it with the goal is i realize like what we need to look at is the source code is the binary code itself we're going to have to look at the raw binary code there to look for specific patterns uh in the binary code that help identify the version of log4j using as little log4j code as possible too right because you know maybe what if someone only

grabs uh 30 of log4j in their system but happens to grab the vulnerable part like i mean that's sort of that would be insane if someone was like you know what i just want 30 to log for j in my system but you know it's uh i guess it's conceivable and and that that saying that i live by is if you can imagine it it exists it does exist on the internet somewhere if you can imagine it so i wanted a detector that would be robust against all these possible ways of taking off your drain and distributing them and so let me show you what i came up with in the end and we can just go to the log4j detector

itself log4j detector and see the horrible logic make this a little bigger we're going to go into the source directory and here it is log free data these are just utility classes just to help with you know the json you know because people asked for a adjacent output for example right oh here have a json output then this you know parsing and dealing with the strings and the output um and so here's where it's actually happening open source uh log4j detector you know uh public repository you don't need to talk to you don't need to talk to us we are you know a vulnerability scanning company we we make a vulnerability scanner but you to

use this tool you don't need to talk to us it's only it's on github it's public so what we ended up doing is when you look at log4j itself um right so if we look at the um the library inside it you see this this sort of um structure right there's these subdirectories right so good core async core filter core pattern so we look for um this this path this structure and it turns out right like if you have a file called core and log event and core dot appender and cordial filter if you have like these um you know these five files then you probably have log4j2.x on your system and if you have this then you probably

have log4j1.x on your system and if you have this file well this file only showed up after log4j 2.10 right so you can imagine i just spent like you all probably probably a couple dozen hours just crawling through the blog4j because log4j itself of course is a public open uh apache published piece of software so i just looked at all the versions of vlog4j and just tried to figure out when did this file show up and then you know once i actually figured out so when did this when did these files show up and then and then i realized in addition java because of the way java works these string literals are part of error

messages or part of property lookups well string literals are actually stored as is directly in the bytecode right so if you have an error message if log4j is going to say something like invalid jndi url you know it's going to complain um with some error message it turns out that error message will be stored directly in in the class file so you can look for that error message and since i realized that that error message only showed up starting in log4j 2.15 you know i can use that to be like okay well because i see that error message i know that we're at least 2.15 or newer right and because i see this config option as a string literal like this

sequence of bytes occurs in the class file then i know we're on 216 or later so yeah it's just a combination of looking for files and directories and then within those files and directories looking for byte patterns um that were present and what's nice about these file names and these byte patterns is um they are stable like there's nothing you can do uh to perturb them uh through compiler variation or through your environment no like these are core aspects of log4j that no matter how you build it build it on windows or package it up in some weird way or only download you know half of vlog4j to just the bare minimum to get you doing what you want you know

these are the things that are going to be in there now you know when i'm saying like this only download 50 of that that's just me being crazy that would i don't think it would do that yeah so that's how i did it in the end it's just looking in in the um looking them through the source code and looking for the things that were stable that i could almost use as as flag posts as markers to to really um be certain that these versions of log3 were present and then you know on top of that you have the whole um you know the whole like uh jar anti jar inside jar etc my scanner does not do tars right

my the reason i don't do tars is just i've never in my experience as a job well there's two reasons one is um tars i i don't there's no tooling that i'm aware of uh that can stream them like can that can recursively handle tars inside tires in a streaming fashion you'd have to you have to dump them out to temp files and i just didn't want to deal with temp files in this library you know it already was doing enough um yeah outputting to temp files preserving the structure and then cleaning up after you're done i was just that was too much for me for this quick little uh utility whereas with jar files you can actually in zip

files uh because of the way they're structured there is good utilities including in the jvm for for just pure in-memory operation of them right and so i never had to deal with temp files but on top of that and probably the same reason is i just never run into a situation where a tar file containing java code um was being executed on a system right because uh because java just the execution oh it's always war files or zip files or jar files so probably if you have a tar especially tar.gzip it's uh it's you you it's not great that it's on your file system but probably it's it's very unlikely that it's being executed in any way

yeah so um yeah so that is my talk on on log4j and and how you would find it i think the main takeaway really um is like if you if you got scanners um like if you've got a vulnerability scanner like uh dependency check or black duck or merge base um i really encourage people to put together uh synthetic samples um ahead of time where you know it's vulnerable and you know that you've seen code deployed in this way and just to make sure that the scanner finds it like i've been doing that a lot lately i've been uh putting together docker images where i would take like a log for jhr file and just copy it into the docker

image just be like here just be here in a random directory in this docker image here log4j.jar and then i would say okay snick tell me what you think or or quay dot io well tell me what you think a red hat tell me what you and none of them find it right they always are like they're always saying like yes we find all the vulnerabilities but it's like if you just huck vulnerable war files vulnerable jar files vulnerable dlls directly into these docker containers they don't seem to find it so i i i really encourage yeah everyone when you're evaluating scanners or if you currently have scanners vulnerability scanners and you're not evaluating them

maybe reevaluate them right like literally once a year once every six months just be like you know what let's throw some weird files at it and see what it thinks or let's throw our own files at it the way we package software the way we deploy software let's do a do a little package of your own software precede it with um with vulnerabilities but do it all the way that you package it and then see what the scanners think um okay we have tim saying a specific file specific configuration parameter um recursive unzip fine grebish would identify its present oh yeah yeah okay one thing that's neat about java now this is um this is a

quirk of java in that um when java's tooling creates a jar file java's tooling will be like oh you're putting a jar file inside a jar file well i'm going to skip compression in that case because you're doing a jar fill inside a jar file i'm not going to compress the jar this inner jar file um right and so because of that that meant the table of contents on the inner jar file is not perturbed word of the day perturbed and so that meant you could do a recursive grep so if you did a recursive grep for um let's see for like if you did a recursive graph for j and the i look up

right uh dot class just this this became a very powerful grep because you could just do a recursive grep for that but it does it is assuming that that means the jar file was created using maven or using uh the jar command not the zip command because the zip command doesn't feel the same way the zip command is like oh jar file inside of jar file let's compress that whole darn thing let's try our best zips like even though they know they even though we know recompressing a zip a second time is useless the zip command doesn't know that but the char command does uh and then zanita how long did it take me to build the scanner the log produce

scanner um it took about 10 hours to get the uh initial version of the door um because of course i um i just based on you know my deep um passion for jar files and java and also some um research ideas that i've been um being chatting with with my supervisor my old master supervisor we've stayed in contact and he tells me his ideas now and again like probably a few times a year we get together and he had mentioned that identifiers uh class names and even inner variables tend to be globally unique like there's this this crazy um thing that happens in the software world where you know this um i mean of course in the java world we're

making them um globally unique on purpose but like for example nosql pender probably is globally unique that's probably a globally unique name uh in that no other library in the world no other software system in the world will have that name i mean of course once you add log4j slash core or slash appender that's globally unique on purpose but it turns out even this probably is globally unique so i was and so he my supervisor for my masters that's i mean that's what he specializes in and so he's done some research on that and so he kind of gave me that idea that you know you don't need that much of the name just a little bit like core slash

layout boom that's going to be globally unique so that's the fact that that pattern has was on the file is gonna is gonna be all that you need it's a weird um unintuitive result in the software engineering world yeah so 10 hours to get the first version out and then then dropped another 30 hours into it over the rest of december because i got the first version out on the sunday right after log4j dropped log4j dropped late on a thursday night and i had the detector out by sunday and then as github issues and bug tickets came in and i further improved it probably put in another 30. so 40 hours in total

yeah zanito my pleasure yeah and um i guess i will stop sharing screen and yeah thanks everyone thanks for coming and uh yeah be careful with all your files out there um there could be bad things in them and uh be careful with your scanners because you gotta you gotta exercise them it's like flossing once a year make your scanners find the vulnerabilities that you proceed with them precede vulnerabilities into your files to make sure your scanners are still finding the vulnerabilities like they should bye bye everyone sayonara

you