 Hey everyone, welcome to rotten code aging standards and Ponying IPv4 passing across nearly every mainstream programming language Let's get started So I'm just starting off with a meme here. I got from JF or Joe Swabic Twitter account everyone Please stay calm or releasing PSC's for the unpatched vulnerabilities. You can better evaluate security posture. I Thought this was fantastic And I asked Joe if it was cool if I could put in the presentation This is a quick disclaimer none of the research today was paid for it's all in good faith Nothing today represents our employers future past or present None of us under any gag orders apart from vulnerabilities that are still pending You'll see on the next slide all of the content in the slides is creative commons zero And all the trademarks logos blah blah blah are property of the respective owners So what we'll be discussing today, so we'll be discussing today a litany of CBEs These are CBEs that we accumulated of the course of that last I'd say nine months With some of them still pending because they're quite large and they take a bit of time to fix obviously So two of them will be releasing today that have never been seen before and we confirm with all the vendors and everything like that That is cool to talk about them including the Oracle one. We've mentioned below. We're getting to that a bit soon So the format of today's talk is how to be following this type of vulnerability How you as a researcher or a hacker can horizontally scale your own abilities whether that be for good or for bad Some proof of concepts for some of the vulnerabilities the exploitability of a vulnerability this caliber or type and Further vectors or attacks or research that can be conducted by anyone who is willing to get involved Some takeaways we want you to take out of this is that every day is patched Tuesday patched Tuesdays a meme No longer exists except for maybe a Microsoft or Oracle and how do you patch an entire class of vulnerabilities this size and just a quick Apologies to anyone who has to leave the conference early because some of these vulnerabilities might affect some of your code bases and Lastly, we just want to show you how to exponentially magnify some of your research threat medals or thought models to magnify those attacks and once again horizontally scaling your research so Applying it across all different types of languages and also the ability to pick up existing vulnerabilities and apply that across existing code bases whether that be Finding a vulnerability in one language and then applying it in the next language and so on and so forth so I just want to start with a quick picture of a typical NIST CVE scorecard Basically 9.8 That's the maximum you can get for a vulnerability excluding scope being changed or unchanged and this is all what you can expect from a Pretty high caliber vulnerability where you can get remote code execution or server-side request forgery or things like that And just quickly as an intro you're listening currently to sick codes and you'll be hearing from Kelly Curtis soon We'll be presenting work based on some of the work that we did with John Jay hacking Nick sale Osala Victor VR leg chin who and Harold Hunt So I just want to start with the octal numbering system Most people understand this numbering system, but basically there's no eight or nine You can kind of visualize this numbering system as in counting to ten except you're counting with closed fists And you're counting from zero and you've only got eight fingers Therefore you're counting the maximum of seven and then you just start from the next number up So that would be ten which would be one and zero and how do you get to this? Numbering system from what we know as decimal. Well, the easiest way to do it is you just go from left to right on a number That's been prefixed for the appropriate octal Formatting you basically start from left to right and then do eight times the power So this number here has three digits. Therefore we go to one and zero So eight times two eight times one eight times zero and then we multiply that by each digit in each box So one times eight to the power of two Zero times eight to the power of one and then zero times eight to the power of zero And this one's really easy because one times eight to the power of two eight to the power of two 64 So one times 64 and the other two multiply by zero or nothing Therefore the answer is just adding it all up you get 64 Now let's go to a more interesting case We got the one at the front again So we got 64 second one there eight times two is 16 and then the last one there Anything to the power of zero is one therefore seven times one is seven add it all up. You got 87 And this is what we traditionally know as decimal or base ten. This is what we've got ten fingers for One times this is exactly what you do when you know normally counting numbers is you got your hundreds your tens and your ones So ten to the power of two is a hundred ten to the power of one is ten ten to the power of zero zero Pardon me. It's one and then you got one times a hundred is one hundred And you got your two times twenty two times ten is twenty and seven times one is seven to get one two seven That's your typical base ten or your Real-life numbering system that you currently know is decimal or regular numbers To go backwards from octal between decimal to get from decimal to octal. We do remainders So hundred twenty seven divided by eight is fifteen remain to one keep the keep the remainder on the right-hand side Fifteen over eight is one remainder seven and then one remainder eight is zero remainder seven and then you get the The octal number is the right-hand digits Basically you lined up next to each other like a one seventy seven So notably from that example, you would have obviously been looking at the one two seven a really recognizable number This is a check host if anyone doesn't know it's an awesome website Russian website believe there's no Capture anything like you just plug in an IP address you can ping it You can mainly what one of the things I get out of it You can discern between DB IP maximum and I think it's IP to address or something like that You can maximum you can maximize your you all sent by comparing the three and calculating where a database is getting its Geolocation from in some cases So zero one seventy seven if you put that in your address bar You'll actually go through to your home address But if you put that without those your under the throat, which will allude to later You actually get to a Brazilian IP and I'm not gonna Blur this IP address out because it's pretty well known but one seventy seven dot o dot o dot one is somewhere in the middle of Brazil and then the reverse of this is the Resolution of zero one two seven which goes to eighty seven dot o dot o dot one and that's some random one in Italy I think before we were looking at this that was owned by level three communications But it looks like someone else was actually Taken up the roster on that IP address there, which is quite interesting So this actually this vulnerability as you can see where it's kind of heading is based on the fact that some passing libraries I'd say all of them pretty much have some sort of nuances in the way that they pass IP addresses in that Daniel Stenberg Who runs the curl project he? Fixed this in 2018 on the lean-ups or canoe side where 177 with a zero on the front which means octal would actually resolve to the funny address that's located there in Brazil And he called it a funny house, which I thought was quite hilarious and the part of this Presentation we're alluding to in the terms of rotten code is that a lot of people have different ideas of how code works and Implementations and standards and changing Schema things like that It's not a blame game but a lot of languages have turned bugs into features or Things that they've added along the way have actually been the incorrect way to add them or there's typos or there's manipulation or even there might be Code that's been inserted maliciously through I guess road commits But another part we want to allude to is how well tested use some of the libraries you've been using and how well do you trust those libraries? This is an interesting exit We got from Wikipedia in the in the term of octal a lot of different ways You can prefix numbers to represent octal numbers a lot of people might remember the backslash 73 is being the most common way of Referring to octal where by zero oh is actually Typical of octal and then zero X is typical pexa decimal and that's true in C And then furthermore that was actually taken up by a python. Oh Camel Haskell Raku Ruby TCL PHP and then we've got ECMAScript, which is actually JavaScript space rule structure or standards and We'll get into that a bit later on but there's actually some confusion there based around the standard so that ECMASix and a couple three and a couple five are all different in the way that they Should or shouldn't pass octal values And this has been discouraged in quotation marks that does not mean that it's been Employed but I'll just quickly say for the record you can use the use strict to avoid this kind of instance So a lot of IT devices that don't have the sort of capability or even memory allowed a memory allocated to the device where it can actually realistically or Reliably pass on IP address passing IP addresses should actually be the same sort of meme as passing HTML IP addresses are a bit complicated in that if you do a while shark you'll see the mac address pop up You'll see the IP address pop up in hexadecimal, but what do you want sees octal? Okay, so that's a little thing that a lot of people are missing is the octal usage of numbers everything boils back down to libc So depending which operating system you're on we knows can We'll keep winners aside for the moment but all of its based on Translating network addresses from hexadecimal into something readable into either 16-bit network representation 32-bit Etc etc or even into the octal format The reason is for using that the reason we do that is to obviously use it in other programs So programs like a program communication So this is really funny me me yelling at my computer because my code isn't doing what I want it to do and then On the other side my code is doing exactly what it was told to do In this picture here, we've got a This is just a while sharked up just to sort of emphasise the Packet itself and what you can actually find out of the packet Let's you click on the different parts of the packet and identify what's there Obviously if you're a bit more savvy with the network address translation, you just see the Bites themselves or the other way to do it is just to click on the source address for example 10 Dot 8 dot 160 dot 2 3 5 I believe I'm behind a VPN and then you can see each individual by it there the four bytes are represented As the actual integer values 10 8 1 6 2 3 5 and that's the full IP address But where did the dots come in from well the dots come in from translating so they're not actually part of the packet That's where the kind of the issue lies is that most of the translational errors come from people Not understanding that or skipping parts or just human error But the only real reason that people use octal is kind of like just basically for testing out SSRF And that brings us to our first Entry to the story here, which is the Node.js project private IP which has got something like 12,000 weekly downloads we came across this about nine months ago when John Jackson and Harold came across this vulnerability when they're working and One of the vulnerability purports they received was in relation to SSRF. So someone was able to request Server files belong to the server when in the real world They weren't actually supposed to receive those files and the way they use that was using SSRF techniques involving Submitting octal numbers to the module and getting to a publicly facing module and getting back private files that belong to the server and And just for reiteration here, and this is 12,000 weekly downloads of this project the project hadn't made updates and for about three years and What a previous year it was a bunch of regular expressions in a form that I would probably say is unmaintainable some people would beg to differ but the Maintainability of rejects in this format is quite hard for someone to just come along as a newbie Particularly if they don't know rejects or if they're not that strong or familiar with it But there's better ways to do this Well, we thought at the time a better way to do it was using big Sitterbox and sitter ranges so you can see here. We've got let private ranges. We've got a bunch of private ranges here that we allocated And just here just quickly just showing you the private internet. So this is just a really classic document from 1996 Where they've got the RN reserve ranges as specified. These were the free These were the three basic ones at the start as you clearly see point number six security is not addressed in this memo some examples of where Public Idre public IP addresses may or may not be used is like Arrival and departure terminal displays at airports, which we now know clearly need TCP IP and Then cash registers obviously they use TCP IP connected to the WAN now Money machines all that sort of stuff. So they've got some of this wrong Banks weren't supposed to be connected to net now. Everyone's literally banking on the net. So and Then yeah, two of the addresses that we had in the tests were actually We're actually false They're actually incorrect because they are actually private IP. So they shouldn't have been in the public IP address test case for the original Package public IP we removed those obviously and then we added a bunch more test cases there This is the new IPv6 rejects the Vasco and other maintainer from the Lib Lib PTP, I think they added IPv6 as you can see rejects is rejects You either love it or hate it. I love it. However in this kind of context, it's not really Maintainable to a level that we'd expect for application that's used by X amount of thousand dependencies And that's probably the reason why the original package was not updated for three years and rejects So here we're looking at The second module that we found was netmask. That's the one we added. You're looking at three million weekly downloads This is a big one. This is a lot bigger than the other one. I'd say in magnitude in order of magnitude larger 9.8 critical for this one with Harold and John Jackson So here's the first CD we had insufficient rejects in private IP 1.0.5 was in this insufficiently Filtering ranges that were actually supposed to be private ranges And that's why people could actually submit URLs to applications using this package and that she get Files that belong to the server, which is obviously disastrous and Then after that because we'd actually added the netmask project in there Someone actually came and found another vulnerability and then One thing led to another we actually found out that netmask itself was vulnerable, which was hilarious and you can see here that It's pretty much exactly the same vulnerability And then another guy named riot act came in midway or another researcher named riot act He came in halfway and actually found another Cve because the complete fix wasn't actually correct And this was only scored a 5.3 because I think was only out for like two days Although it is the same impact as the first one So we're in Tmux in a container. I just wanted to run through the netmask Cve So this is the last vulnerable version before we started making changes with the maintainer And we're just picking an arbitrary cider block 31 000 slash 8 First address in this block is 31001 last address and So then this block should contain 31 5 5 5 However, this block should not contain 0 31 5 5 5 because 0 31 is 25 in Decimal if we convert it properly Now we'll see the same thing in coffee. I wanted to show coffee because netmask itself is originally written in coffee And it's transpiled to node Okay, that's the same and Unfortunately, that is also the same now. Why does this happen? Underneath in the netmask library This function parse int is being called and so parse int if it's not passed a base as the second argument We'll just chop that leading zero right off and pretend it got a decimal when 0 31 should be 25 It'll just come out as 31 And we're gonna see the same thing in coffee Unfortunately, even though coffee has the advantage of not accepting leading zero notation otherwise, right? so we should be using 000 if we really want octal in coffee All right, so what? So back in 2018 again Nikola Gregor responds to curl guy tweeting about Octal he says yeah bad octal conversions are a legit way that we can use to get around anti-SSRF filters if you haven't heard of Nikola He's associated with port swigger as an official burp sweet trainer He teaches people how to use one of the most popular web app hacking tools in the world And he references his talk from app sec Euro 2015 and says yeah, if you're interested check out pages 24 to 28 of my slides So it's pretty clear that this is an accepted way to get to a place where we can achieve SSRF Once we can bypass input validation, we can potentially execute local code Around the time we were doing this research in March The node net mask package had about 238 million lifetime downloads So it's a bit more popular than private IP It had around 2.8 million people downloading it directly every week about 170 packages public in npm declare it as a dependency 289,515 packages on github declared it as a dependent last we checked the dependency graph as well So it's pretty popular for a node package. I'd say In AXA's original write-up on bleeping computer. He mentioned Perhaps rightfully the pearl component net net mask which inspired no net mask net net mask had the identical flaw and its maintainer Joel was very quick to file a CVE and Push out a fix pretty much as soon as the article came out or slightly before which is very commendable And it also kind of lit a fire under us We were having a good time looking at things or at least sick John and I were So then we started looking at other cider parsers and trying to see well, okay What else could there be out there in the world that does this exact same thing and doesn't quite work the way the maintainer intended So the last time this package was updated was 2016 which is fairly reasonable cider parsers don't exactly change a whole lot This is another package a bit like net net mask which inspired no net mask within the pearl ecosystem So we've installed the vulnerable version We've got our proof of concept on the right and the deal with this package is you're supposed to use a guard function is Underscore IPv4 before you call is private underscore IPv4 or is public IPv4? And we didn't do that because it wasn't documented that you needed to do that before the fix The documentation was changed as part of the fix So we're just gonna run it and show you the output here real quick and so like with net mask and everything else the Idea here is an attacker could submit input data Which is in octal which should be private and ends up pointing to something that is a false negative Which results in SSRF bypass and same thing with things that should be public and are not So there's a couple of things that do work here a couple of things that don't work here If you wanted to exploit this you would just sort of have to experiment to see what was going on But the trick is guard function If you're a little bit confused you actually go to seek doc codes and in the releases section You'll find a big write-up about the original net mask vulnerability And how it affects you it's actually quite a large write-up. We go into all the details about that vulnerability And they're sort of a table Where you can compare net mask to decimal and then the reverse of that and what you should expect But what I'd like to point out is the comment section So in the comment section is a reason for the double check So that was actually a small zero day that came through in the comment section Another one in the comment section was padding for an anonymous user So IP address, I mean, this is just zero days getting dropped into the comment section Which we I didn't approve them at the start, but I did actually end up approving them because it's been enough time So you can see our pad your octals you do all sorts of crazy stuff and then Lauren's the only reasonable thing is to consider IP invalid trying to convince some people that it should be considered that is futile and I tend to agree with Lawrence because only IP addresses without 8s In the octal range alphabet So you literally I'm missing 20% of your entire address space so yeah And one comment from Tony from Tony Choum. I tried to get in contact with Tony He was one of the guys that mentioned to us early on that Java is probably worth looking at and we did actually not looking at that I'll email Tony and Tony. I hope you hear this, but yeah, I appreciate The heads up I couldn't approve you coming at the time because it was technically zero day, but we've been in touch with him. Hopefully Ping back When you're initially learning about a type of vulnerability It may make sense to try and find it everywhere you can like if you're trying to figure out how a reflected XSS works It can be interesting to try that on Basically everything you come across and so we applied that to octal a bit We knew we had some leads to go on from some of the things people were saying And there are just so many vulnerable cider parsers that even when we were putting this talk together We were still finding more so not only is it Possible that there are more out there that are vulnerable like this. It is quite likely So if you don't really get what's going on at the moment Basically, we're just applying the same CVE to a whole bunch of different languages a Python pearl go lang Java Java script in the form of Node.js and another pearl one and here's the one by Dave So we opened a issue at Chromium project stating that the V8 engine is wrong Because 8 doesn't actually exist in the awful octal alphabet after the number 7 is 10 And that's relating to decimal only So it's apparently working as intended and we open up an issue on ECMA and They've said they don't want to fix the issue because it's too old It's not even a bug apparently But yeah, so you have to be just up a deal with it Going over to the Mozilla developer reference for a second to check out what it says about these errors that we were Discussing with the Chromium team. We see a couple of things here So firstly as mentioned by the Chromium team octal literals the leading zero format literals which represent octal integers We'll throw an error in strict mode, which is nice But this doesn't exactly help us with either net mask or with the behavior of parsant Which still allows zero prefix literals and put as strings or integers even in strict mode so the second thing is Javascript mixes zero prefix literals that get interpreted as decimal with zero prefix literals that get interpreted as octal And we find this one of the weirdest foot guns we've encountered so far with Javascript aside from Parsons behavior To explain this a little bit since the only digits in base 8 are 0 through 7 This means there are some extra zero prefix integer literals allowed by the ECMA spec and they get interpreted as decimal After the Chromium project we opened one at Node.js itself see if they could do something about it Mozilla apparently doesn't treat it as a legal octal constant. That's be good as it isn't there's like there's only seven numbers and so v8 rejected it Node.js rejected it and Pretty much then the last The last opportunity we had to raise the issue was with ECMA itself and I said that these numbers don't exist They said websites will break and the end of the discussion is No one has claimed this doesn't make sense Just that we can't change it because it break it will break a bunch of websites. So the bug Has moved into feature status So he will present a Rust CV go lang CV a Python one and some Oracle stuff So Cheng sort of decided for rest that they would just reject zero prefixed octets Which is likely the right decision So leading zero on IP string interpreted as octal literals Simple demo here. We see that Zero one two seven becomes one two seven when it shouldn't be Yeah, this may cause security vulnerabilities in certain cases The specification also allows hex formats and IP strings Yeah, so the end Result of this is only decimal is allowed in Rust which is Better for user input. Yeah, it's not at all obvious that we should parse octal IP addresses seems exceedingly unlikely to come up outside of security advisories. Yeah So this made it into one point five three point zero, which is super cool Congrats Cheng Fixing the comments Fixing the code and referencing the same RFC draft as the Python thread did interestingly So which says that octal is a rare format for user input for IP addresses and we shouldn't parse it Yeah, if number Starting with zero is not none. Then we don't you know, we don't want to mess with that octet. So tests To make sure that octal things are error hex things are error And let's just run the little proof of concept from our CVE So this is the version of Rust from before the one with chains fixing it I'm gonna compile it real quick and Then you'll notice that we're changing Individual octets at a time. So second octet third octet Fourth octet and then the first octet. So we've got zero two six zero two six zero nine three and then zero nine nine at the very bottom and None of these are translated correctly. You know same parsing logic applying to all the octets With goaling folks had been talking about limiting the size of allowed octets for a while So goaling would allow you to just throw a correct ten of zeros in front of something and allow it to still be treated as decimal So like zero zero zero zero zero one nine two would still be one nine two But really all you need is three digits to get to two five five Which is the max size and decimal for an octet. So when our write-up came out people started talking about it in the same thread and Go lang eventually decided to mimic what rust did and return an error on zero prefix input Which is good because it avoids the ambiguity of allowing Both octal and decimal especially when zero prefix octets are probably just a footgun that most would rather not have So here's the change made it into one point one seven Thanks, Roland Docs change We now reject IPv4 addresses which contain decimal components octets with leading zeros And then this is just a little check on that first digit. I guess reject non-zero components with leading zeros boom Here's our proof of concept from the CVE and we're looking at octets one at a time again the last Two little sections here are just trying hexadecimal We're trying some of the things that we knew worked with net mask and kind of shouldn't have So we're trying, you know, some cider purses will also parse IP addresses that are just a single integer and so that's what the last one is Second to last is just throwing a random hexadecimal octet in there for grins So we've got it built we're running it. Yeah, so the hexadecimal ones don't work which is Encouraging but the octal ones do that zero on that leading zero on those octets that are in An octal format just gets stripped off And so just the same as decimal is how they end up being treated Which is not what we want of all the languages we looked at that we found to be vulnerable I think Java was my favorite. So we're running 11, which is the LTS version. So compiling it real quick Yeah, so we're looking at one octet at a time again and Up to 255 we are interpreting as Decimal we're just stripping that leading zero right off and then zero two five six becomes one seven four Hexadecimal on the other hand seems to be fine Fewer dotted quads, which is a format I noticed in the documentation seems to work out fine What else get by address I need address get by address seems to work fine Java net URIs seems to be fine. Java net URL seems to be fine. It's just I net address get by name and funny thing about Stopping interpreting as decimal at 255 is probably somewhere There's something that's looking at three digits out of an octet and trying to figure out what it is So after some back-and-forth with the Oracle security bug triage team where we were like well, it's broken And they were like well, we're not really sure why and also It performs differently in different environments We simply weren't sure whether for ourselves the issue resides with the underlying C libraries Properting system or with the JVM or with the Java compiler And obviously the question comes in there where Java actually is supposed to run in a virtual machine aka JVM The difference is basically that if you run Java code just on any operating system without a JVM Obviously you'll get different results and the benefit of that is that you can see the vulnerability being played out between Applications, however, it won't actually pay out the real world unless using Java outside of a JVM So we tested against a couple of different JVM's just to see what would happen and as well across different operating systems so JVM wise we tested using hotspot and Also against growl and we saw our proof of concept code perform consistently. However We did see different results across different operating systems That's where obviously the security team from Oracle decided to just say it's not really a bug and it's the responsibility the responsibility is actually downstream related to libc and does not affect Oracle's product and we asked them if it was cool to actually discuss that and They said yes, so that's where we are So these are just some examples of cider parsers Where we took the time to investigate and discovered Unique ways for handling octal the point we're trying to make in this talk is Very few people actually handle the octal IP address format correctly some of the other Languages which we didn't look at but could have include Lua and Ruby and maybe someone else with interest can come along behind us and Take a peek at some of the other things out there During this work we came across a wide variety of articles and blog posts and just opinions about how IPv4 parsing should actually happen But not so much in the way of a single formal definition From a discussion around a reference IPv4 parser in a blog post that Dave Anderson wrote back in December For such a simple-seeming idea it is hard in general for people to agree on what an IPv4 address actually should be Well, I've read the spec but most of it is cursed so I'll just implement this subset which fits my definition of acceptable The textal representation of IPv4 still doesn't have a single standard Grammars or other specifications for the IPv4 address format do come up occasionally in RFCs like 1918 which is the private internet one that we talked about earlier and a variety of drafts that were simply never ratified for one reason or another and incidentally also in the definition for IPv6 The representation has evolved over time and this in addition to people simply not knowing where to turn has led to a bunch of Certainly different definitions that mostly interrupt rate, but sometimes just clash in fabulous ways a Handful of the reference definitions out there simply say something like dotted decimal form and just leave the rest as an exercise to the reader If you want to truly parse IPv4 addresses This is the bullshit you have to put up with and we do IPv4 is still the most widely adopted IP address format currently IPv6 has according to the internet society been operationally deployed somewhere since at least 2002 and Became standardized just in 2017 Currently only around 35% of the internet even supports IPv6 according to Google stats So until IPv6 achieves wider adoption, we'll just have to keep on with IPv4 as well Pretty much anything we used to parse IP addresses Whether it was originally intended to parse IP addresses or not is just gonna have some interesting ifs ands and gotchas So back in Chang's Rust pull request. He mentioned RFC draft 6943 Which is from all the way back in 2013 if the parties involved in a security decision use different algorithms to compare identifiers Then failure scenarios ranging from denial of service to elevation of privilege can result The authors do a decent job of walking through exactly what we've shown in this talk And so here's a little table They're using a couple of different different terms false positive and false negative a false positive means two identifiers were equal But should refer to two different things like the octoliterals parsing is decimal literals and netmask and other places For example zero one seven seven Equaling one seven seven so on the other hand a false negative would happen when two things should have been equal But we're not like zero one seven seven not equaling one two seven when compared this draft has existed since before a lot of the code That we demoed today Not everyone reads spec before trying to implement something or even knows it would be useful But it does come in handy as a researcher when you're trying to understand how something would behave ideally Back in 2019 Python decided they wanted to remove any and all Checks for octal. Just you know, it's a rare IP format. Who really needs that gosh. So here's the pull request where it happened So here's changing the tests No more error message No more no more ambiguous rejection Leading zeros are ignored and are no longer seem to specify octal octets. Yeah, that's the good part And so we're gonna look at the issue where this pull request is discussed And which was reopened following our net netmask report here again in a second And so they're actually referencing an RFC which rightly says octal is a rare format. You shouldn't handle it Unfortunately, that leads to inconsistencies with other programming languages Utilities written in other programming languages the underlying operating system. So You can't really ignore it even though you'd rather once now that we've got octal We've sort of all got octal. So in This case having octal off by defaults Would be a better outcome, but that wasn't what they did so we're gonna look at Python 3.8.0, which is a vulnerable version and We're gonna run this little proof of concept which Victor and sick wrote here We're gonna run it with pseudo so that the network calls ping work So you'll notice that Linux is handling 010 correctly But Python is not just like we saw in the pull request Yeah We've got our suspect IP rate and we've translated it using the IP address call And then we have fed it into ping twice once as itself and once as translated into the bad IP Bad IP stays bad Suspect gets translated correctly We got this far because we worked as a team and we were able to pick up across time zones None of us got paid to do this. We've all been collaborating in our off hours whenever those happen to be We'd love it if people were a bit more skeptical of the battle-heartedness of their dependencies in the future We'd love it if there were a formal definition for the IPv4 address format or at the very least for how to handle IP address Octets in base 8. We'd love it if ECMA rejected zero prefix literals containing decimal digits But even if those spec changes happened there would still be code out there were some things just slightly wrong Spec can guide future researchers or programmers and understanding the differences between the ideal world and whatever issues have become features But it's not going to magically make things perfect If it's critical for code to behave a certain way It may be useful to ensure the behavior of your underlying dependencies matches your expectations before you rely on them One thing we did find really useful was the ability to report these issues to the security teams at all the various organizations and At least discuss and get pointed in a different direction if necessary If we hadn't been able to get in contact with the folks at Rust and Golang and Oracle and so on these vulnerabilities Would continue to be live in the most current versions of these languages and libraries So thank you so much to everyone who is receptive to working with us to fix these issues and thank you for watching our talk