Good afternoon, welcome to Fuzzdom. My name is Alain Urenic and I work for Synopsys where I manage R&D for the seeker agents. Now before I get started I'm sure many of you are looking at the session's title and asking yourselves does this guy even speak English. So before I

get started let me address this unanswered question and assure you that in fact I do speak English. This title is of course a reference to a very old video game called Zero Wing.

If you don't recognize it let me reassure you you are not missing anything and this pun is not really funny. If you do recognize it you don't need my reassurances and you know for yourself that this pun is not actually funny. So bad humor aside let's get started

and let's talk about bombs. Bombs are class of attacks class of security vulnerabilities where an attacker can send a relatively small payload that then expands or glows up because

we're talking about bombs and consumes a huge amount of resources on the attacked system side. It's a form of denial of service attack where a lot of resources usually memory are consumed and so since this is done your system can't serve legitimate requests because it doesn't have any

memory left for instance. Now bombs are a serious issue and this all sounds really dangerous and perhaps a bit too serious for FOSDEM. FOSDEM is supposed to be fun that's why it has an

F in its name point. So let's not be this serious let's have a couple of laughs. In fact let's have a billion laughs. Now what we see here is a payload of

an XML variant of an attack called the billion laughs attack which is a type of bomb. What happens here is that we leverage the XML capability of defining entities. So we have the entity lol0 which is just a string lol and then we have the entity lol1

which is a sequence of 10 lol0s and then we have the entity lol2 which is a sequence of 10 lol1s and so on and so forth. So this doesn't look too intimidating right? It's pretty

small XML. How bad can it really be? Well the answer is a lot. So I did what any good nerd would do and I crossed it out. So over here I'm displaying the number of levels of lol that we

have in the payload as the x-axis and on the y-axis we can see the total size of the payload and the total size this is expanded to in memory. So I got up to seven levels of lol's.

At that size the payload is still really small it's about 650 bytes which is completely negligible but it expands in memory to 28 megabytes which is insane. Now I would love to continue this graph but to be honest at this point my benchmark just

crashed but you can roughly see here that for every level of lol that we continue the expanded size shoots up by a factor of 10. So with eight lol's it would be about

300 megabytes and with nine lol's it would be about three gigabytes and the input size would be not that much bigger probably seven or eight hundred bytes which is again minuscule. So this is definitely a serious issue and

and attackers can definitely use this XML expansion to cause a lot of damage. So what can we do to defend ourselves? Frankly pretty much. First of all kind of the obvious

solution don't use XML. This of course isn't always possible and some systems rely on XML and of course you aren't going to change your entire system just because someone at some session in Fuzzdom said so but if you don't have any XMLs and you

aren't parsing any XMLs you can't be vulnerable for do an XML bomb. If you have to use XMLs well the cardinal rule of security still applies. Don't allow tainted inputs in your XML. Don't allow outside input outside data

data that can be tampered with to determine your XML structure. Again this isn't always possible if part of the flow of your system is uploading an XML file you could hardly say I don't allow tainted input in my XML parsing.

So we need to think about something smarter. Different alternative is to continue parsing XMLs even if they come from tainted data but just use a simpler or excuse the language a stupider parser.

Not all parsers support XML entities. In the JavaScript ecosystem these parsers are usually JavaScript wrappers on top of natively implemented parsers like node xpat or libxmljs

and it's fork slip xmljs too etc. Now the JavaScript only implementations like xmljs and xml2js sometimes don't have all the bells and whistles and specifically these two

don't support defining entities or expanding entities which if you do need entities is a problem if you don't need entities why do you care you can just use a simpler parser and

as a side bonus defend yourself from this attack but as we said this may not be possible you may not be able to switch parsers maybe you do rely on XML entities maybe xmljs or xml2js just aren't fast enough and you need the performance of libxmljs.

So if you must get to know your parser and get to know its configuration options for example in libxmljs based parsers you could set no int to false and just disable

XML expansion disable entities altogether and that will make you not vulnerable to this attack or you can just cap the size of the flag called huge set it to false and there's some built-in

limit to how large this XML can be expanded to it's not great I personally would have loved to have a bit more fine-grained control to find the limit myself but more often than not huge equals false is a pretty decent default value and it provides a pretty decent defense

against XML expansion and of course if even this is not an option if you do absolutely need XML entities in your program and you do absolutely need very large XMLs

not everything that is large is necessarily a bomb and there's a big difference between a large input or an input that expands to something large which is valid because that's

your business logic and some nefarious attack or bomb just designed to create a denial of service attack so if you absolutely have to have this at the very least sanitize your input there's a number of libraries that can do this personally I usually use XML escape which is

on the one hand pretty simple on the other hand pretty solid should be good enough for most use use cases where you have to upload an XML or even take some user input and

concatenate it or interpolate it into an XML so we've seen there's quite a lot we can do we can build something that's reasonably defensible but I want to revisit the first point sure

this has crossed many of your minds a lot of you are probably thinking well XML is this old format my cool new application doesn't use XML it's too old school for me

I'm writing a cool modern application I use YAML well I've got some bad news for you YAML also allows you to define entities and if it allows you to define entities you can also create a bomb in that format so what you're seeing here is the YAML version

of the billion laughs attack so again I see this input and I have to ask myself how bad is this really it can't be that bad can it well sorry to tell you it can so like

before I went and I graphed it out I took my benchmark up to seven levels of lulls

not because I wanted to stop at seven but because my benchmark crashed seven and you can see here the expanded size in memory grows exponentially when I got up to seven levels I had a YAML payload which was a bit over half a kilobyte about 530 bytes which expanded in

memory to 66 megabytes and I'll leave the interpolation of where where this goes next up to you but you can trust me just keeps going exponentially and keeps getting exponentially

worse so unfortunately just using YAML instead of XML won't save us so what can we do well I alluded to this earlier of course if we can avoid using YAML again no problem

no YAML no YAML entities to expand no bombs but this isn't always possible a lot of our applications just use YAML can't change the format again very similarly to the

way we handle XML bombs if I have to use YAML or if you at least have to use YAML at the very least don't allow tainted input in your YAML don't allow an attacker to control your YAML this

both means just uploading a full YAML file or even sending a string that is somehow concatenated or interpolated into a YAML although take the opportunity to say that with YAML you can essentially introduce entities any way you want as opposed to

XMLs where you cannot so one might even say that YAML bomb or using tainted input in YAML is even more dangerous than using it in XML so take care and be really really careful

well but as we discussed previously sometimes I can't avoid using YAML sometimes I can't avoid my attackers excuse me my legitimate users from introducing introducing their own data to the YAML

so what can I actually do well with YAML bombs actually the past YAML in memory isn't that bad most libraries that I saw actually do a decent job in just holding

multiple references to the same object which yeah isn't quite from an application developer's standpoint but from a standpoint of conserving memory that's excellent

but you need to be smart about this okay you can't just say well the library protects me I passed my my YAML into a memory structure which is fine and now I'm just

JSON stringifying it out there that will just lose all the benefits of the deduplication instead actually use the methods your library provides so with you with the YAML library you can use stringify with the js library you can use dump and you'll get a string which

just references the same entity again instead of expanding all of them so again it still may be large but it won't be ridiculously huge sometimes we can do this

sometimes we can't sometimes we actually want the expanded output we want to see all of that so going back to our playbook if you do want to see your expanded in YAML if you do have to use JSON stringify once again get to know your libraries

most of these libraries allow you some way of protecting yourselves the YAML library has a max alias count which limits the number of

entities that can be expanded like this you can set it to minus one to disable this feature altogether or to some reasonably small number that makes sense to you the default if I remember correctly is 100 which for my money is a bit large but find what works for you

in JSC YAML I'm not aware of a way to limit the expansion in such a way but you can just disable it completely with no refs equals false again if you can if this suits your business

logic so I think I'm running out of time let's wrap this up we've talked about bomb attacks in general we've seen the XML example we've seen the YAML example

we've touched on quite a bit of options how to prevent them and I know that if you have 20 slides in the session your audience will remember two or three sentences so what do I want you to take away from here first and foremost think about your formats think about the formats

you use whether it's XML or YAML, JSON which is a bit safer in this regard but may have other problems get to know your formats get to know all the caveats and get to know where your formats

are maybe too smart for your own good there are legitimate use cases for YAML entities or for XML entities in most systems that I've seen the systems business logic doesn't really need this

so perhaps a simpler format for instance JSON could have done a better or safer job if you can't change your format get to know the parsers you use get to know the technology

behind the scenes don't just assume smart defaults and assume you can just require a library called dot pass and everything will be okay most of these libraries at least the good ones the popular ones have very good documentation and they document all the parser options

you don't have to know them by heart but if you're introducing a new parser read through the options the default may not be good enough the default options may be there for some good reason but this reason may not be security get to know the options get to know

what you can disable get to know what you can't and with that I think I'm really out of time there are any questions I'd happily take them after the recording until then I just want to say thank you for your time thank you for listening and have a great conference

good hello everybody thanks a lot for your presentation it was interesting I suggest now

you might answer to the questions oh so first of all thank you for having me here in Fazdom and also want to thank Andrey for the previous talk I know Fazdom has a security track but

I think it's critical for us security professionals to not just concentrate on the security track and go out and talk about security where the developers are for instance JavaScript track in this excuse me in this case okay so let's take some questions

looking at the widget here question from Steve it's easy to turn off entity expansion when you know the issues it causes but is there anything you can do in anticipation of a bomb for product or feature being created um so I'll separate this question into two first of all

if you are if you're implementing a new feature and introducing some new library or new format first of all as I said in the recording get to know your libraries before you introduce anything

read the documentation there's usually a huge list of config options you can switch on or off and most libraries will not be secure by default unfortunately so I like to start by reading through the documentation switching everything off seeing of course my feature

does not work and then kind of switching on on one by one all the config options I need until until I get something working and as you do that each time you switch something off

don't think about it for a minute and just blindly switch it off because you switch it on sorry because the application doesn't work in read into it and see see if there's any literature about this being exploited or not and how you can prevent it or not or obviously how you can prevent it or what you should be thinking about and the second

way to address this is if the second way to understand this question is if I'm creating a new feature for instance I have my own alone format instead of using yaml or xml what do

I need to do then this is kind of trickier but first of all kind of stop and think there's a saying if you have to reinvent the wheel make damn sure you're reinventing or you're inventing a better one so don't really need a new format or can

xml or yaml or whatever just do this for me if it cannot again it's really hard to be smart in advance and try to anticipate all the ways people can use or abuse your your

application or your features it does take a bit of a mindset switch to see okay this wasn't intended but what if I try to instead of sending

one legitimate entity send a thousand or a million of those not always easy to do um usually usually the best approach in my mind is to use something something like a fuzz tester

there is a really good library for javascript which I actually use but I'm drawing a blank on its name the company was acquired by gitlab about one and a half years ago

and do not remember it but if you search npm for the fuzz testing you'll probably find something that can help you and other than that on an infrastructure side so even if you really have this vulnerability if you're using any type of intelligent orchestration

regardless of if you're running a container or a vm if it's on your own infra or in a cloud cap the process so yes an attacker will be able to kill the process but you know if you need

let's say a gigabyte of memory cap it at a bit of a buffer 1.1 1.2 gigs so an attacker could be able to crash the process but they won't crash the machine if it's yours or if it's on the cloud they won't crush your wallet while they're doing it okay um new question from

bloom the cherry I know you quickly mentioned json but I didn't quite fully catch it does json also have this or similar problems so out of the box json at least simple json not json

5 as far as I know does not allow referencing entities so you won't have this bomb type of vulnerability here if you build something smarter on top of json pretty sure json 5 does that

although I've not seen this actually exploited so short short answer json is usually pretty safe against bombs unless you build something smarter on top of it and there is a dust

vulnerability in passing json synchronously so you should be careful about it and the recommendations kind of go back to most attacks cap it if your application needs 100ks of json don't allow any attacker or any legitimate user to send a megabyte or 10

megabytes of json just cap it at some reasonable size okay so that's it from the widgets

let me take a quick look at the chat itself to see if anything else has come up okay um it does not seem so so I have about 50 more seconds before the next talk so

I'll use them to once again say thank you everyone for listening thank you for them for having me and have a great conference