It looks like you're having connection troubles. Reconnect now.
01/25/2022 22:09:47
30c3-talk-5499 Latest text of pad 30c3-talk-5499 Saved Jan 25, 2022 |
Hallo Du!
Bevor du loslegst den Talk zu transkribieren, sieh dir bitte noch einmal unseren Style Guide an: https://wiki.c3subtitles.de/de:styleguide. Solltest du Fragen haben, dann kannst du uns gerne direkt fragen oder unter https://webirc.hackint.org/#irc://hackint.org/#subtitles oder https://rocket.events.ccc.de/channel/subtitles erreichen.
Bitte vergiss nicht deinen Fortschritt im Fortschrittsbalken auf der Seite des Talks einzutragen.
Vielen Dank für dein Engagement!
Hey you!
Prior to transcribing, please look at your style guide: https://wiki.c3subtitles.de/en:styleguide. If you have some questions you can either ask us personally or write us at https://webirc.hackint.org/#irc://hackint.org/#subtitles or https://rocket.events.ccc.de/channel/subtitles .
Please don't forget to mark your progress in the progress bar at the talk's website.
Thank you very much for your commitment!
======================================================================
All right. I think we're about to get started. Let's take a seat and make sure that the usual announcements are there's nothing blocking the aisles. No cables, no bags. Nothing else. So nobody trips over and we can actually empty the room if they have to. In an emergency was that I would like to introduce Ilya. He's the director of up and testing it active. And most of you probably know him. He's been looking at the Exxaro code, the Examiner system code and things he found there. And I'm sure it's going to be very interesting. Had a few chats with him before. And yeah, please give him a warm welcome and let's hear what he has to say about it. Thank you. So my talk is going to be on ex-security, and the subtitle is It's Worse Than It Looks. Pun intended. So am I. As I was just introduced, I worked for a company called Selective. I am their director of penetration testing. I run penthouse and lead penthouse, and you quote reviews and basically break stuff for fun and profit. In short, my talk is going to be, I'm going to do small intro. I'm going to talk about security of X clients. I'm going to talk about the future of X servers and then we'll have a sort of slide at the end where I'll sort of be like, Well, how bad is it, really? Is there anything we can do about this? So what does this talk about? It's the importation of X work parsers, specifically how the data comes in either decline or server, how bad or how good that is. And also also say something about specific trust barriers. Entry points into either the exclusion in the X server, and I'll show some bugs and trends of bugs that sort of show up and vote decline on the server side and then a near general sort of have to slide where say, Well, how bad is it? What can we do about it? Specifically, what does this talk not about? It's not about the network operations site, right? We've known for a long time. Yes, if you have Network X and you don't tunnel little for six h, people can stay if they can do keylogger
all that kind of stuff. This is well known stuff, so I'm not going to cover that. I'm going to talk about implementation and not network side of things. So as far as a deduction goes, I actually start looking at the stuff about a year and a week ago, right before the Congress last year, I decided to download the X11 client code and sort of look, I look for receipt function and then basically from there start looking at some of the parsing. The client code was fairly easy to grasp and sort of find the entry points within a week. I will run through all of it and sort of weeded out all the Low-Hanging Fruits report about 80 bugs. They all got fixed. Almost all of them. But all the bugs themselves got fixed. And then sort of as of May, June this year, I moved on to the server, and initially I was like, Oh, well, you know, it'll take me about a week, and it turns out it took me much longer. I haven't really finished yet. Service is enormous. There are so many extensions I've not finished yet. Thus far, I have reported hundred twenty bugs about 25 hours ago. So the server bugs have not been fixed yet. But before we're talking about server, let's move on to the clients. Some easy observations about X, in case you didn't know yet, is that it's a it's a client server protocol to be used for deGruy and pretty much anything that's Unix and has a gooey has X even on Mac OS. I guess it or Apple doesn't ship X courts anymore, but most people still install it. The server is networked or can be networked can be of GCP or IPC. It's a binary protocol. The client basically passes, or the client person becomes interesting when your client runs with high privileges. So if you have an Israeli binary, for example, that's interesting attack surface from the X client perspective. And the reason why is because if you have a privileged Australia application that uses X, you can basically say, Hey, connect to this malicious X server and will go there, and it will fetch all of this network data
, which you can spoof and send in malicious data. And turns out getting it to crash is really, really easy. So in case you don't know what X looks like, kind of sort of looks like this or it looked like this 30 years ago. So the excellent libraries are basically these acts of advice, if you look at this thing. They don't have a pointer, but so this thing is here that that's the attack surface, right? So I spent a week looking at all the libraries that sort of fit within ZLIB. There's also there's ex-hubby. And people have asking me, Have you looked ex-KGB yet? Have you looked there yet? I have not looked ex-KGB yet. It's on my to do list, but so are a hundred thousand other x related things. So I'll get to it at some point, but have not looked excited yet. Going back to sleep, but I can tell you that things are unbelievably bad. It's all by the protocol parser. See, it's all code is written in the 80s. The server, basically the delivery was written in 1984 with the idea that the servers trusted, and so there was very, very little validation done. Yeah, as I said in a week, something like 75 bugs or something. So it was instantly obvious that that core was never written with a trust boundary in mind. And so with that, since since the bugs have been fixed, I can now talk about or show an example of some of these bugs. So here's I've got a set of examples, and here I'm not going to read through all of them, but I'll all sort of run over the first three or four and then I'll sort of skip through the rest of this court because spending entire hours looking at code is kind of boring, at least when you have an audience in front of you. So but just to give you an idea of how bad it was, these are things that sort of the first hour you look, you start looking at scored all this. The stuff just sort of falls out, right? So basically, the first thing I did is I downloaded all the exit code and I just grep for underscore x reply. And right there, that's all your entry points. A
nd so there's this disrupt thing is basically, did you get back from the server? And then X returned to his basically reads more data from the server and it takes this link value, which to server gives the client and the client just blindly trust it. And so the client can say, Hey, I've got four gigabytes of data for you, and this pixel buffer is not as much smaller. So this these are trivial memory corruption bugs. Two of them, another very trivial bug, is basically, you know, you do x reply replies it. It comes back from server and there's basically a memory location on based on this data, trivial textbook intro flow right there. Another example is Disney that came from its reply. And then one of the elements who uses an index into an array without any kind of validation trivia. An index bug textbook example. Here's another one where. So this doesn't doesn't use underscore extra play, but uses to get window property, which is basically a wrapper. Earthquakes supply gets back a number of items from a server and basically just doesn't copy on those items. It does link checking, but it turns out these links have nothing to do with the length of the items. So it's it's a pretty stair step memory corruption bug. There's some puzzle I've got like 20 or so in here. So if you if you download the slides later and you want to look at this, you can see just how bad it really was. But just to give you grasp of the overall bugs, I found there's a there's been a set of these bugs that were found of OK. And that's just that. I think that's toe sitters like four times that many that were found so older, discovered bugs have been fixed. It was really cool when I submitted a book. So usually when you submit bugs, you never quite know what you're going to get. Sometimes you will ignore you. Sometimes people get very defensive, sometimes people will be lazy, and it'll take two years to fix a single bug. I was very pleasantly surprised when I submitted these bugs to ex-security securi
ty security expert. Within a couple of hours, I got a reply back from one of the developers, Kenyan Alan Coopersmith. This guy needs to shout out this guy fantastic. He fixed all the bugs within within a three month period, 80 bugs within a three month period has a very deep understanding of X, which not too surprising because he's one of the developers. But the good thing was usually when you use when you report bugs, people will they'll you might not understand it. I might have the security knowledge. And so you have sort of hold their hand and they'll say, Oh, that's not a bug, and you have to go back and say, actually, it is because of so and so and so didn't happen a single time and every single bug I send them. He instantly understood and saw what the consequences could be. There was no pushback, no hand-holding. It was fantastic. Allen worked tirelessly. I mean, to do this kind of looking over and understanding 80 bugs and then making fixes for those 80 bugs and reviewing the device and then doing all the testing within a three month period is pretty. I mean, that's like Superman, right? So that's really, really good. So. Yes, exactly. Yes. In the top of that, I also have to be in a conversation with him regarding the bugs that are found. And so Al had some interesting comments. This one is actually a serious one in the next one or sort of more funny notes, but I may not read the entire thing, but he sort of starts off saying, well, and this is this is where he shows how much, how good he grasps that, that that there's a trust boundary and a security element to the tight lipped who says, Well, I don't know how many set you had. And I never mentioned statuary to him. So he says, I don't know how many said you would still exist these days as extras around so and so and so. But since we know there's more xxxxxxx lines than we can keep track of, especially ones home grown ups and various companies and so forth, we have to assume there are still some. It would be
good to put a reminder on our security advisory the best practices to separate out parts of the application that require elevated privileges from degree to avoid such issues. Cheetah care requires this, but not all toolkits do, and I'll get into that last part in a little bit. So these are other observations he made. These are less serious, but kind of funny. I think it was like, shoot me down and shoot this developer for not fixing ex-KGB and anybody else who touches KP because it'll be too late for them to. And it goes like, well, after my analysis of these first batch of 80 bugs, I got so tiny in my head start spitting, trying to figure these things out. And then one of his comments, one of bugs were, you know, if you have a windows shape of two to the 30 30 second rectangles and what the hell are you doing? And there was an endless stream of this sort of kind of funny comments on them. These bugs where eggs allows for these very liberal things that no one would ever do. But it turns out, if you try to do, is going to blow up anyway. But they don't stop it. And then what was really cool is when his bucket fixed, there was no LW and read about it, and it was sort of the, you know, just LW and trolling. But among the comments, there was one that I thought was just perfect. One of the original X developers commented that he said, I just want to sort of read this the first part of it, because it's really sort of captures how bad the state of X still is today. He says, Well, all I can say is it was 1984, and it was a very, very different world. We're talking over 25 years ago, many LW readers weren't born. Then there weren't many bad guys out there. I remember the worse Moore's sperm hitting, which was way beyond. It was after 84, when I was working on X 11 protocol bindings and Kevin Mitnick had just reared its head a year or two before super bugs. I clearly wrote in that period and others copied my mistakes. Others just utter and clearly made mistakes, Ryan says. Ot
her bugs just couldn't happen in the practice of the machines that era. So you have to think about macro facts. And so some of the book just, I mean, it was like, Well, you have this four gigabyte text file. And if you parse that, then the thing blows up, which today is very easy to do. Thirty years ago, it was impossible to sort of fall out of when these bugs got fixed was interesting because so no shadows to Debian. So what happens is when you when you submit bugs to X, they say, Well, we'll go fix them and then they won't have this too. So after they have all their patches, an intricate repository to have this two week embargo where they go to all the vendors and say, Hey, listen, here's our fixes. We'll keep it silent for two weeks and you get two weeks to get your shit together and then we'll just release the whole thing. That works pretty well when you have one or two bugs, when you have 80 bugs. Not so much. Debian was the only one who would in the two week time frame, merging 104 patches, all within a two week embargo. Full reasons why On the day the embargo expired, no one else managed to do this and the guy mostly responsible on the Debian screen time. I hope I'm pronouncing his name correctly. Mauritz moonroof deserves a lot of the credit for this, so I think we should all just. So this is the silver nice, but nobody really uses Rolex anymore when you write a good program for that's going to work next. Nobody uses x slip, right? Everybody uses these frameworks that are built on top right. Sediqqi Kuti motives. There's a bunch of these, right? So I start looking at some of some of these and see, you know, is it better or is it worse? Solomone, Kata and Kuti and scrappiness is bang on par with excellent, trivial bugs like this one where basically you have an array of five elements and then you just take arbitrary data back from network and just start copying it in until you run to the end of the array of data. You got back without validating that if it's bi
gger than five, you should have build out. And they didn't. That's sort of the standard stack smash. This is cute in it. So any cuter application is vulnerable to this, where basically, if you give it a certain an app name in a certain circumstance, they'll they'll give you. They'll still app that name, global pointer and assign it your RV pointer, which comes from Maine and an adjudication of court, will assume that it's it's been new to C++ nude and they'll do a delete over a pointer that's R or V. Clearly that's going to blow up, and there were a bunch of these bugs, right surfboards to the the cute guys. And their response was just night and day difference compared to the skies guys into the courtroom x developer earlier on about the set up and the the all these frameworks not having separate checks before it is dead on. So cute doesn't really have those security checks. And so when I the bugs cute, the kudos. You guys did not agree with me at all. They said the mail back and say, Well, you know, Katy is trashy ones that you the application to check pass for this very reason. You know, I suspect some someone running sue at jury duty applications would fall to a huge number of problems. The most obvious of one being a malicious styles that would allow them to trivially execute code. So basically what I send them bugs. And their reply was, Oh, here's more all. Not the response I was looking for. So respond back and saying, well, you know, it's it's your library, you don't you shouldn't dictate policy and there are in fact, more CDs you ready. Binaries specifically mentions KP because I found bugs in there in the past, and I know it's still around and I know it's still at least being maintained. And so on top of that, I cringe doing the style things because I really want to know if there's actually executable coding there. Just to be sure they gave me a zero day. So they basically mill back and say, well, you know, that would be a security, all those applications r
ather than duty. There are many ways people could have used library to create unsafe applications. And then I go do styles. The issue was quote, and they say, Yes, they do. And then I asked, and, well, escape, you no longer run, as you said. And then this is this is beautiful, right? The quote from the frequently asked questions of KP. But they cut off the quote. It's an incomplete quote. Sort of quote they give me is there is no need for the set. You leave it. If you know a bit about you ministration, simply create a modem group adult users that you want to give it access to the one group to that group and make the modern device read write about for that group. Not that hard, but not all distributions come pre-configured like this. There are, in fact, still a bunch of cave piece that you had instead of doing this. So anyway, that's their partial quote. And they say then they sort of speculate I doubt any modern distribution when thoughts that you had. In fact, most are extremely careful about this. Yada yada yada yada. And then say, Look up the exact quote and this this thing is true. But it goes on to say the KP team has lately done a lot of work to make it you safe. But it is up to you to decide if you in any way you install it. But we put in a lot of work to make it say you are at least safe, which means they would be OK with having it set you ready. And in fact, I looked at Ubuntu, and if you install KP and Ubuntu by default, it set UAD route. But the more important issue is here is that their library Courtright, as long as you use their APIs correctly, they should allow for Israelis to call them or they you know that. So what's what's really bothering me is that they're sitting on the fence because it's easy, right? They're saying you shouldn't do this, but are not enforcing anything, right? So either defend it and shut up or do a security check and exit right? They're not doing it or just sort of sitting there and saying, Oh, not our problem. So none of the b
ugs are fixed. So the bugs I just gave you earlier, those two kutty bugs, those are zero-day. But the really cool part was, I got there, OK to give you the zero day. I asked them if they consider as serious as they're not considering a serious issue. Can I talk about this publicly? They go like, Yes, sure, go right ahead. So here you go. Two zero days. So that was sort of the cute part. I don't know if any. I don't know how well you guys know the Unix environment, but in Unix you have this sort of standard LDPRELOAD, which is you can sort of change the way change which libraries you load when you start an application that's been made. You say in the 80s, early 90s, there were problems with that for students. This has long been made safe. But of course, those frameworks Katie Kutty know they must have their own Elderfield equivalent, right? Kids, school or school suddenly called Kutty plug in pat enormous something called JDK modules. Neither of these are set. You would save at least two key modules. Things is somewhat known. And as you say, people seem to know what they're doing and they're aware of this problem. And so what they did is, or what they're saying is that they don't allow you to adjudicate applications and they have a website clearly explaining it. I'm not going to read all this. If you download slides, you can read royal thing or you can go to our website. It's adjudicate or exactly what HTML explains the whole thing. It's kind of dry and boring, but the gist of it is this quote, right? So if you read the whole thing, it's really beautiful. It's well thought out. It's saying whoever wrote that policy, it clearly knows what he's doing on the security side of things and sort of the cordon there is basically or sort of the the money shot is security of JDK plus requires the security of slip. Digital Key Plus team is not prepared to make that guarantee. That's a pretty good. That's a pretty good thing, right? I wouldn't make I've seen her code. I wouldn't
make that guarantee either. But is it really true? So I go and look at their claim, and it has the right before they do the checks that you ready. They have a comment, explain the whole thing and say, Well, this check is there just to see if you had a USG at the current time. And so if it is that we we don't allow you to get to be initialized and we exit, and then they go on to say, but it's only meant to be a mild check. We only erode if we can prove the program is doing something really wrong. Not if they're probably doing something wrong. For this reason, we don't use is set up by DMP. As your PR CTO, get dumped on Linux, which is the proper way to do it. They didn't do that right? So what does that mean? It means you can still have supervisors adjudicate. Plus you just can only initialize you decay after you did a proof drop. So that means you have to you have to. When you write your program, you have to first acquire all the resources you want, drop your privileges and then run JDK, which means if you have a bug in it, you couldn't immediately escalate to root. But whatever privileges are still there, you know, secrets and memory file descriptors, IPC handles, all that kind of stuff. You would still get to see all of that if you if you if you get exposed to bug. So it still kinda sorta allows for the applications. It just becomes like a tad bit more difficult. Games are a great example for this, for example, right? So there there's a there's a bunch of gnome studio games and what they do is they share a high score database file. And so the reason it proves is to open a read handle to that high score database file. Once once they have that handle, they drop all privileges. And so now let's say there's there's there, there's a bug we could exploit or we would use the key modules, right? All sudden, we have code executing inside that set uad high score file, and the previous resource that we want is the handle to the highest score file right now. Let's let's say,
for example, there's a secondary bug in the passing of the high score database because the database not considered trust boundary because it's it's it's a trust resource. Chances are that pass is going to be really weak. So let's say there's a bug and that we know how to exploit it, since we have that rewrite handle to the higher score file we write or, you know, our show code or whatnot properly into the high score file. And then when any user plays that games, they'll get owned by trying to discover file, right? This is just sort of a potential case where this can come up and be a problem by far. One of the most common bugs I saw when you slipped. So I said earlier that X get window property is basically just a wraparound underscore extra player, which basically is a wraparound receives, which takes raw bits from the network. This is the most common bug that I found when I was looking through people using it. Basically, the way I get window property works is that you hand it a pointer to a pointer, and when a thing succeeds, it fills in that pointer with something to locate it. And then when you're done, you call free on that pointer. But when you get window property fields, for example, to mark fields that put it never gets initialized to zero. So if you don't check retrieval, you always assume that the thing succeeds you. You're also ended up using a pointed out was never initialized, right? And so you end up freeing arbitrary stack memory, which is bad. The really good part is I sort of mentioned to Allah said, Hey, you know, this isn't really a problem, but it's a common Paterno sign. He says, Oh, we forgot to initialize this thing on failure. So he goes and puts an. And this is no longer this was a problem for 30 years in usage, but it was it wasn't it was never importation problem. Right. And so Alan winning anyway and said, Well, we're going to fix it anyway. So after two years, this problem is just gone. It's never going to happen again. And basically, so
when I said that for the next get window properties, a wrap around extra ply, these are sort of the standard. All of these functions are sort of ex client wrappers and all of these basically take bits from network and sort of hand them off to a bunch of passers. So these are good things if you're if you're looking for X line bugs, which is great for these functions and those are all the entry points. And then there's a bunch of property wrappers. So these are basically all just sort of take a bunch of bits from that work and sort of hand them off to passers. And that's all I did, a grep for these functions and sort of sort of reading what they did with which data they came back in a week. There were about 80 bugs, conceptual leaders, basically. So the idea is that people. So one of the responses was on LW, for example, when these advisory came out was that, oh, well, this isn't really a problem because there's no actual applications around. Turns out it isn't true. You take any given standard Linux distribution or whatnot and just do a standard grep for suit apps. Half the time you're going to find at least one or two applications that are set you out of your set gedi that they'll use X in some way. And you can point of two lists X server, and getting them to crash is going to be really, really easy. But generally, conceptually, there's a set of X associated applications around configuration tools like AVP games, like a bunch of gnome games and screen locking tools. Your X Log X like more xscreensaver before they do early dropping, but they still have some, some interesting resources in memory. The good thing is that I mean, in in early in the late 90s, most of these things have still ran his route through the entire lifetime. Nowadays, though, they'll do that sort of the right thing or as right as they can to get older, privileged resources they need and then drop privileges, which means if you have a bug and they're doing a pivot to route is not going to be easy o
r not going to be instant, but you will still have access to all the privilege resources that those programs hold. So this is kind of my client summary, excluding this or this is a bad idea. People think there aren't any around. There's more than you think. Just, you know, take whatever little box you have, do a scan half half, there's a 50 percent chance you'll have at least one or two assorted binders that use that use. Excellent. So it's it's more happens more often, you think. But you do get a plus kind of sort of soulless asteroids. They're not the cases in the clear as they as a as they make it out to be. In the last part is that this this was so this this thing was really more a symptom of a bigger problem. But when you read applications that use, actually there's an enormous sloppiness when they use the APIs, I didn't really zoom into it that much. But if you just if you have some free time, just go download a bunch of budget apps that use actually and just start looking at the way to use the the actually APIs have time almost this calls or they're misinterpreted, or they'll do all sorts of very sloppy things that you know, it's just sort of if you if you were a developer in in the 80s or maybe even 90s, that was OK today, not so much. But then again, most of those apps are probably written in the 80s or 90s. So that was that was the client side. This is that stuff I did in December last year and I didn't punch prestation the client stuff. The server stuff is much newer. I've been reviewing it on going on and off in the weekends. And when I have time since May or June, I'd say June, July, August is what I did most of the time. And then there was sporadically a few days here and there, and then yesterday not finished. There's a lot of code. I'm lazy and then I know I don't forget those galaxies all zoom that later. But you are basically the shell bindings for X window system she likes. It's horrible. It's terrible, it's terrible. It's about eight hours lines
of sheer terror. It has six or seven. No, seriously. It has about six or seven callback tables, and each table is anywhere in size of 74 to 400 eight. There are several thousand callbacks there. Basically, all of them are attack surface. All of it takes data from from X, and most of them are broken beyond repair. It's really horrible. So just trying to sort of. Keep reading she likes quote, it's horrible, it's it's a terrible motivator. You know, it's one of these things, you know, when you read code and you find a bug and you copy paste into a text file because you want to do a formal write up this one, one of those rare occasions where you get tennis elbow from old copy pasting. So you remember this? No connection I showed earlier. Total lie, it x doesn't look like that anymore. Has it looked it looked like this in 1984. It was designed to be this way. Doesn't look like it anymore. It hasn't looked like it for at least 15 years. There's a talk. So there's a guy named Daniel Stone, who I referred to earlier one of the comments by Alan. He's he's one who used to be one of the developers. He moved on and sort of is now a fairly famous Wayland developer. So Whalen, sort of the next four are sort of the replacement for X. That's in the works. He did talk earlier this year at some Linux conference in Australia. I have a link there. That's if you have some free time or take a picture from that link or something, you should watch it. It's very, very informative. He sort of goes like, Yeah, X doesn't look like this at all. Actually, it looks more like this, which is fairly more complex. And so I don't want to do in this too much. But this is so this is basically your client stuff and it's still your server. But then there's a part in kernel and there's a part where you get direct memory access and there's a part where you get shared memory. And then there's basically you get memory Matteo and those kind of things. And so when I say server in my slides, technically this is
just a server. But when I say server, I refer to sort of all of this, right? So it's a bit wider than just the server, but it's sort of the all the things the client talks to. I considered the server. So let's let's take a step back from that sort of go back to the initial and let's start with the beginning, which is what they designed. This thing that needed for the first thing they did is they they made a core protocol, right? It said, these are all things we're going to need. The court protocol is straight C code. But when you read it, it feels very it's one of those things where it feels very object oriented, scored. And so this was written in early 90s, if it was written 10 years later in the early 90s, would have probably been C++ code not saying it's it's better or worse, but it would have probably just been because of the way he designed or coded would have probably been C++. The code is fairly good from a security perspective. The core protocol is actually not bad. But I think that's I don't think it was initially like that. I think over the years people have found bugs and so you can see the things where they passenger overflows, right? That that concept of a buddy of mine calls it a polished turd. But X is certainly the X corporate protocol is a good example of that. So the core protocol itself has very few low hanging fruit standing thing has actually been looked at throughout the last 30 years. So what does the court protocol more or less looks like if you happen to have the court there, there's a call dispatch shot see which contains the mean dispatched dispatch loop where connections come into the X server from a client. And then initially, all the client can do is only call two procedures. One is to initialize the connection and wants to establish the connection. The initial connection basically just does set a set of very standard things like Hey, this is the byte order. Because X can do both little and big Indian, you have to give it a byte order a
nd then X will take care of old Eddins for you behind your back. That's what initial connection does, and I'll get back to that in a minute. The other thing you have to sort of establish after you do that, you have to establish the connection, and that basically means authorization depending on the way you set up your X server. That can mean very little, or it can mean a lot, depending on the way you configured it. Once you get past initial and established connection, clients can now talk to full core protocol to X, which which are about 80 or 90 procedures. Requests are initially limited to 64K. There's a big request extension, which everybody uses it has been using for a very long time, which allows up to 60 megabytes per request. But initially 30 years ago, people, while 64 key, ought to be enough for everyone. Turns out it wasn't. I'm. So when a client sends a request to the server, the contents sort of comes into this fairly standard type linked value header thing. Any any any procedure you cause, it's sort of on request, but every request starts with the same basic three types, which is the X request header type thing, which is the first eight bits, which is the type, the next eight bits, which is called data, and then the next 16 bits, which is the length, right? And because that link 16 16 bit, initially you could only have 64 K when you have. The bigger question is sort of Mount Mount Mount a 32 bit length on top, but we won't get into that. So what does this mean? Is that when you send something over, it's that shorter than these four bytes, it will automatically get rejected. It will. It will never make it through to X. X will just be like, this is too short and throws it away. So anything that comes into X that gets accepted, it's going to be at least four bytes long. The type basically gets validated in a sense that zero 227 is Core X protocol. Anything above that are X extensions, and basically so that basically says like a type of hundred and thirty t
wo would be extension x y z, and then that extension would need its own subtype. And then we got subtype is done. There's no standard way are the extensions get to pick out a subtype. It just turns out that most extensions will just take this data thing and use that as their subtype, but they don't have to dig into it any way they want to. Right, so once you get there and the clients get called any procedures they want, there's a to call back tables actually a table start C, not surprisingly, once called Proc Vector and once called Swap Proc Vector, and they're essentially exactly the same product, Vector contains all the 80 or 90 procedures you can call in a SWAT. Proc Vector is the exact same thing, but it does swapping for indigenous and then once it did all the swapping, it goes and calls into Proc Vector and then the core protocol basically does what the core protocol is. There's a but I'm not going to get too much into detail here, but there's a bunch of really, really boring and old specs about this and the basically out to create destroy inquiry windows and atoms and properties and images and text strings and extensions and all sorts of weird little things. That's in nutshell, the core protocol. So now that we've sort of covered the core protocol, let's move on to extensions. Extensions are basically so X11 is really old, it's 30 years old, it's very old and it's completely broken, and extensions are the way to sort of keep it on life support. And so the way it still works, the reason it still works today to the point where it's not super slow is because we have on any given XS solutions today, you'll have anywhere between 20 and 30 extensions. And without those extensions, you would you would not you wouldn't want to use. It's way too fucking slow. So those extensions for input device now devices and shared memory and using OpenGL, using direct rendering and having, you know, a bunch of drivers not not newsletter, but having vaccine kernel and all that kind
of stuff. And the way you do that we had an extension is by an exceptional extension. And basically you basically go there and say, Well, this is the day of my extension. This is my main processing code. This is my main processing code again, but which does all Indian swapping and then, yeah, that closed down progress, not find half the time and the minor up codes basically testing where because I just said that the exceptions get to sort of picado won't do the old subtypes that miner up code Proc gets to decide what the subtype is. We're talking about extensions as a sort of one state that's a little thing because there's a lot of tests for bugs here, but this is sort of quite complicated stuff. So you can have all these sorts of weird handles in extensions and then they sort of it's it's feel a little bit like Kurland, where you have a handle to a data structure, which has is of some type. And so extensions, you can have all these sort of different types of resources where you can have an outside of your handle to a different type of resource. And there's a set of, I think, 15 or 20 standard resource types that ECS has. But any extension can make its own resource by calling. Creating a resource type by creating a research type basically takes two arguments. One is the name saying, Hey, this is this is what my resource is called. You know, resource x y z. And then two is as a run down functions delete function where basically when you clean up this resource, where all the thing it'll describe or it'll do all the things that you have to do to get rid of the resource and that because you get this kind of very comp, you can have this very kind of depending on what kind of resource you implement. You can have this very complicated delete logic. I found one bug in there so far, but this this is not trivial. This is really complex stuff. We sort of have to steer into one way have this sort of weird things where, you know, if this this offset, but this one isn't, then yo
u know, three guys call this for this never happened. Then this one bit gets said. Otherwise it doesn't. And then it gets set in the wrong way. Then when you delete logic, something would get free twice or wouldn't get free or something like that. So again, very we delete logic. I suspect there's going to be a pile more. But because I was looking for low-hanging fruits, I didn't really look here. But once we get rid of all low hanging fruit in the server, which is going to take a long time, this should be the next step. This is, I think, there's a bunch of complicated bugs just waiting to be found in resource deletion. So, yes, sir, extensions, if you look at a court that's sort of just grep for add ad extension. And these are basically all the the files that add a bunch of extensions in X, right? That's a pretty big list. Some of are outdated. Some of her only use certain circumstances. But in any given recent machine that uses Zork, you could have anywhere between 20 and 30 extensions if you want to see what your extensions look like. I wrote this very, very trivial piece of code. If you run that, it'll tell you exactly what all your extensions are. And if you if you don't, if you don't want to read, if you don't write my code because you don't trust me, basically, there's an API called X list extensions. Just call that thing. And if you're allowed to use it, just read the main page. It's very easy to use, and it's very easy to query all the extensions that your server runs. Clearly, this stuff is private acts of right extensions where all the cool stuff is, because as I mentioned before, the core protocol has been ordered that already there there's very few low hanging fruit. Nobody's ever looked at the extensions, the extensions. It's just streams and streams of bugs, right? For the past couple of months, I've found 120 and I'm not close to done so. I reviewed a lot of extensions, but not all of them yet. Yeah, basically, I'm still to this very day. I'm stuck on
galaxies where it's sort of a never ending stream of crap. And so it's humongous. It's horrible. Every passing routine I've seen so far has been broken beyond repair. Once I get out of this hell hole that's called chill exile, I'll be able to look at other extensions. But I'd like to believe I've reviewed a fair amount of them by now so that I've sort of covered that. So what is a general? So what does the general procedure look like in an extension that an ex client will call into, right? And it's basically, yeah, my I'm sorry. My slides kind of suck because I I wrote them on a Mac on a different version of PowerPoint that I sent them to myself. And this is my Windows machine. And of course, the layouts kind of screwy. Let me see if I can't fix that. This is better. So, yeah, so what does general procedure look like? It's basically four or five lines of code that is sort of a standard template, right? So this this would be your practice that you get this sort of standard client structure back. And what you do is you call this macro called request and request knows there's something called client. And what it does is it creates a it creates a variable on the stack called stuff. Yeah, seriously. It's called stuff of this data type, which is the structure that defines the the the request that's going to come in. That's very specific to my my procedure. And that's what request starts, right? It says it basically declares access, request stuff, equal client user buffer semicolon, and that basically defines all this stuff behind your back and then request size. Match basically does says, Yeah, this is the size of the thing. Make sure it is validated and or if it's not, just bail out. So this does limit validation behind your back. Once you have that in place, basically what you do is you call this, you basically just use this stuff variable. And then that's I just made up a ran a function called use request data. But every time you touch stuff, that's data that comes fr
om network from a potentially untrusted X client. So there are several size macros request size matters. Basically, you give it a type, and it means that the size of your request has to match exactly the size of a struct. If the size is off for some reason, bails out request at least size basically means if the data you send me has to be at least as big as a structure or bigger. I mean, in the last one years requests, I request fixed size, type, length. And basically what that means is it's got to be the data you send me has got to be exactly the the the length of the type plus the length that was given. What's interesting about request size fixed is that it has an implicit integer overflow. Does this led thing right here if it's user controlled and you can make it about four gigabytes big in the overflow internally, and there's really no way to fix it because you can't bail out of it. It's a macro. It's not a function, right? But if you use these macros correctly, that's how you prevent a trivial out-of-bounds read and writes in any procedure for extensions and even the core protocol. So now that we know that, let's sort of go over to standard types of bug. So because so the 100 bugs I found, I reported them about 25 and a half hours ago by now. But because clearly they haven't been fixed yet, I decided not to talk about specific bugs yet because I don't want to drop serially unless people tell me I can't. So what I'm going to do is I'm going to give you tell you about the general types of bugs I found and that sort of the because I've seen enough the code that I know kind of have an idea what the trends are among all of the extensions in the core protocol. This is obviously, you know, a very common one. Certainly not specific. But yeah, if you do remember your, then you get a check return value. You might crash on an open reference if you're out of memory X has piles of these bugs. Obviously, natural flows, right? Big one, certainly when you're passing binary prot
ocols, you're going to have piles and piles of energy overflows when there are three cases that sort of where this happens. One is when you pass large conflict files like foreign files and so forth. There have been a bunch of these where you have very large config files with, let's say, four billion entries or something. Yeah, that's probably going to overflow when parts of portable data, obviously, right? It's even going to be out of bounds reads where you bypass some kind of link validation or, you know, memory corruption when you have an intro flow and viewing buffering calculations obviously seem to have similar wrappers. And then when you have the implicit use of request sites fixed that could have been drove us to, oh, this is sort of that, not an extra bug, but it's sort of cute, this cute little thing where if you do heap allocations in C, you have malloc, real callachan, free and real access as it's really, really cute corner case where if you give it a pointer and a link to zero, a real sort of short circuits, it says I'm just going to free to data and hand back another pointer that's by design. All the manpages say it has to be that way. But there's a large number of C developers that don't quite know about the corner case, including some of the XT developers, because there's a bunch of these bugs within X obviously invalid Lingfield indexes. I actually did have some examples of that in the client side. The server side is not much better. They have a bunch of these two out of boundaries, right? You know, you you have you take a structure. You don't validate the link to just read out a bunch of elements. Yet that might be not about read. Well, the other thing is a byte order bugs. So what I said earlier that that X server can take care of a bite or a for you. It does that in a way it does. That's because like they have the SWAT vector, so they'll have before they call real function, they call the swap function, which does all the swapping that the real fun
ctions generally are written. At least the recent ones are written by, you know, fairly common people like they'll make mistakes, but it'll at least know something is. They'll know they'll have some kind of checking or some kind of interval of checking. But when people write you the swapping code, they they don't because it's this tiny little piece of code that does fix up. So nobody really cares. Nobody. They just want to be done with them. So most of the swapping code is horrible. They never double checks, and because they actually swap bytes, they're not just out about reads. They're out of bounds rights because they swap pieces of memory outside of a buffer. So you get all these sort of weird memory corruption bugs when people do these byte order fix ups. Oh, yeah, OK. Obviously, you know, memory leaks are so not specific, but it's had a bunch of these where they'll do a bunch of Maalox or stood ups or so for it. And then there will be some corner case. No, forget to free the data. So this is pretty much as far as I've come. I had hoped to have gotten further. There is an unbelievable amount of code in there again, fucking chillax. So the rest of the slides I had hoped to sort of gotten there, but I can give you some general pointers as to like, I read some specs a little bit about these things. And there's a tiny bit at the end where I know a little bit because I spent last night reading up on this stuff, but most of the rest sort of is more hand-waving. Yeah, there's obviously has a bunch of drivers and drivers are drivers support, blah blah blah blah. I wanted to look at server side display. Drivers haven't gotten to them yet. This is interesting stuff, but this is pretty direct rendering infrastructure. These are sort of legacy drivers, I guess the phone drivers actually did look at because you can get to them to the core protocol. So I looked at a bunch of different drivers fundraiser. Horrible, terrible. This is old code written in the 80s. Not used anymor
e, but it's still there. Nope, nobody uses a sponsor for anymore. But the way it works is that your X server has a font clean in it, and you can go there and say, Hey, connect to the sponsor of the actual sponsor. And the font portion, that client is just terrible piles and piles of books. Yeah, OpenGL drivers haven't looked at them yet. It's it's sort of my next step because I feel excited. Look, I have to eventually get OpenGL, too. I suspect it's going to be an enormous shit show based on CLX. It's got to be terrible. And it's one of these things where G6 calls into all these APIs or that that the drivers expose. And it's going to be long and tedious work mapping sort of the the thing that Felix talks into these drivers eventually will get to this, but haven't gotten to that part yet. Yeah, Xserve has a bunch of dependencies of libraries. You initially always hardest thing, I figured, Oh, server, that must be self-contained. It turns out it's not your and you see all these references to Pix Man and so forth. And it turns out that some third party library so I had to go and download those libraries and include them in my auditing as well. So there are some bugs and levers, too, but since they're not part of X, I'm not covering that here. The last bit that I want to sort of cover. Hopefully I can do in two minutes is zero, which is called direct rendering infrastructure. This is the thing that makes X really fast, actually. This is also the thing that makes X not network transparent, right? X, used to be transparent, has been a long time in large part due to dry. Well, there does basically says, Well, you know, yes, you'll have to keep all these cool things that we're going to do is we're going to move, we're going to give you direct access. We're going give you the client direct access to the hardware and we'll have some driver stuff in the kernel that manages the stuff for you as you get all this memory mapped. Your stuff and a way that works is you have this dir
ect rendering manager and that thing lives in kernel and it's kind of looks like this. So you have this X11 and an X server will sort of do it for you, but you can sort of make your own and then sort of you get access to cheap stuff. But then you have this DRM, the direct rendering manager that you see there, you'll see kernel. And every time I see DRM, I get it screws me up because when I see the, erm, I think digital rights management and then I go, like, No, it's not. It's a direct rendering manager anyway. So it's the last data speeds that I look in the directory mentioned in the Linux kernel, which is basically implemented in Driver's GPU Duran Duran Davi. And that's basically a manager in this framework. And so when you make your own kernel drivers, they sort of pluck it, plug it in below the DRM thing during drivers, expose our client faces and basically they can have their own AI actors and then they can also expose AI across from their drivers in Linux. So I actually live in BSD, originally have some structure to them. You can say it's input output and you see the lengths initially when when Linux had tools, they required all of that structure. They said I was just the No. We don't care what it means. We don't care. There's no one like stuff. It's the no the DRM IOK tools sort of mount the B as the apples of Linux like tools, whereas there are actual numbers that actually do have bits that contain this input as output. This is a linked field and this is kind of and they add a little bit more on top of that. So the way it works is when you create a driver, you use these these macros and then you say, this is the name this is, this is the AI of my thing. This is my callback for this. I octal and then a bunch of flags here. And those flags basically validate where it says, well, if the flexors route only, then if you have to be corpse's admin. If it's a DRM art, it means you have to be applied it as that. That has to be allowed to render stuff and a bunch othe
r things, right? And this is all Open-Source Linux code. You can you can go look at it if if you find it interesting, yeah, there's certain memory stuff, I'm out of time, so I'm not going to cover that last two slides, then I'll open it up for four questions. The whole X server runs as root. It has certainly done this since 1984. It we've known for over a decade. It's a terrible idea. As far as I know, X work still doesn't offer a way to really do good previous separation. There's been talk about this. I know some mild, super mild, very weak implementation has been done for Solaris to one domain because you guys did this at least five years ago, maybe longer. And the export has got to just steal your music and just be done with it, right? Know music, guys. Know how to do separation. Just get their code. Use it. Yeah. The other thing is that X has this thing called x axis control extensions, which basically means for every, every procedure you call X, there's this thing called x x hooks. And then you can make your own x ace drivers, which allow you to map a security model. On top of that. This is the implements influenced by Linux security modules, and it allows drivers to implement security model. It's hideously arcane. You have to built these profiles. It's a total pain. Yes, I've been told nobody, even though the security module to do this is there, nobody actually uses this. Oh, and by the way, this is an idea from the NSA, so I don't know if I want to use this. So, yeah, inclusion, how bad is it? Can we do better? Good news is I did finish the run of the client side bugs. I'd like to believe or I hope the trivial bugs are going to clean side stuff. Feel free to go. Look, maybe you'll find some more. Plenty. Plenty of bugs left in the server, at least. Yeah, it's going to be a couple hundred bucks left, a trivial bucks left in the server and extensions and drivers and so forth. Maybe, hopefully, when the advisory comes out for the bugs, I report it. 24. I guess b
y now. Twenty six hours ago, maybe it'll scare people into adopting Wayland faster and we can be done with xorg. Yes. Uh. But even so, even if Wayland becomes as big head, which probably will only Wolf's move back to Wayland, there's going to be a bunch of legacy stuff and Exor is going to be around at least not a decade, probably too. And so we'll have to fix these bugs to good side. The good thing is that if the clients had fixed rate, that four from Allen, is there anything to go by this? This is going to get fixed February March if we're lucky. But even so, what we need is a driving force to go to some way to motivate people to go in and really knock the shit out of the server. It's long and tedious work, and it's kind of painful, but I think something needs to be done. That hasn't been done for 30 years. Somebody just needs to do it. And lastly, but certainly not least somebody, some extra help should get off their ass and just implement previous separation. You do it by yourself or take it will be easy, but just do it. Yeah, that's more or less on time. With that, I guess I'll open it up to questions. Excellent, thanks, Sylvia. So if there is any questions, I'll ask for microphones one two, three four and we might have questions on the internet too. So let's go ahead with microphone number two there. Thanks. Do you have any sense of how the quality of Whelan's code compares to the server? I do not. I have not looked at Wayland yet beyond. I see and I see Daniel's, and I've been very interested and very piqued into what Wayland does. I have not looked at their code yet, but for I understand from your model is that it's very different. So in X, everything goes through. The server in servers is big, massive blob of thing that has access to hardware runs. His route from what I understand in Wayland is different where the composer owns everything, and they're just sort of this IPC mechanism. So I suspect the model is going to be better than X. And I suspect they ca
n, if not already, can easily do promote separation of performance dropping. But it's all guessing. I don't know. Thanks. All right. Microphone number one. Hello. Going to be annoying staff with by saying, I do do it. Use the zip code. I do use the X1 server and I do use it in network transparency file. And it all works. We have to use it sometimes for like really low capability terminal class. It all still works and I don't think you even need DRM because like if if you're using it locally, yes, you don't use the visa driver. But my question is what you've said seems to imply that if you did that, if you kind of went back to the 80s and 90s, you used that code, which I must admit I pretty much actually do. Have you significantly lowered your attack surface because you make it sound like you have? Because if most of the attacks are in the extensions you can actually run, if all you want is yes, text on the screen, images on the screen, maybe some video you can achieve that. You certainly don't need OpenGL. You can get, yes, agreed. I know you make a very good point. If you do that, you significantly decreased. I mean, there will be bugs, but it'll be like an order of magnitude less smoothly decrease your attack surface if you're in that position to do it. Certainly on. You know, cheap terminals, that kind of stuff, you can do it. The problem is YouTube is not going to work when you do this, a whole bunch of graphics is going to work. I watch YouTube and I don't use OpenGL, and it works to do really well because I've not used I've not coming out. I think it uses more of the CPU. You know, if, if, if it's because it'll never use the CPU, right? So technically, you're not using all the all the graphics intensive stuff is going to really interfere with other things. You actually want to use a CPU. So depending only when, depending on your tradeoffs, everything else. But yeah, so I don't know how bad it is, I suspect, because you have all these extensions with all the mo
dern things that people do nowadays. It would have been bad. I don't know how bad it is or what situations you might. You might be right? I don't know. I just I just always suspected that that's the way it is. I don't know in what situations, in what situations that's acceptable. But you might be right. Maybe for the average user, it would be reasonable to do it. It would certainly lower your attack surface. I agree with you. Okay, great. That's what I'll do. Now, I think we had a question from the internet. Yeah, I'm always asking if you encountered any significant design flaws in the code that are not easily fixable by a few patches design flaws in the code. I mean, the protocol has some, I guess, and I didn't. I said I was going to talk about it, but I guess I can. Since you asked, I can sort of say two things about it. Well, that's a lot of slides. So I mean, yes, I mean, there have been some design flaws, but this isn't news. This is stuff we know. I mean, it's that it doesn't have any kind of network encryption. So if you just use X over the network as people used to, you have, you know, our openness, different key. And yes, you can tell all our associates, but it's still a shortcoming of X. So there's a cell. There's a set of these well known design flaws with X as to whether I specifically ran into design flaws in X that were known. No, I didn't. There was nothing there that I specifically found there might be some, but I didn't run into any. I hope that answers the question. All right. Microphone numbers very place. What happened, sweet, cute. What's the future for your guest? As good as mine? I have no idea. Are you talking in reference to the bugs I reported or more general? No, the reference to bugs, which I don't know. I reported the bugs. They basically said they weren't security bugs. They said I could talk about it publicly. That's all I know. I hope they will fix the bugs, but they're not the agreed security bug. If you just get a bug fix, that's go
od enough. If it happens to be that it's better for security, so be it. So I hope you're still going to fix it, but I have no idea. Now we have another question from the internet. Yes. Someone is asking if you're planning on looking into desktop environments. Oh, well, maybe I might. My time is limited and there's so much x server stuff I still have to finish. I put it at the bottom of my list and maybe, you know, 10 or 20 years from now, I'll get to it. Now is that can I please ask you to actually provide feedback for this talk as if it's all the other talks that you visited? You find it in the plan. There's a little link because I'm sure earlier appreciate it. I certainly find the talk very informative and entertaining as usual. Saw another round of applause. Finally, I thank you very much.
