 Thank you. So hello DEFCON, I'm David. I'm here to talk about terminals. I actually came through four terminals on the way here, from the other side of the world. My flight got rerouted, so that was four airport terminals. But that's not what I'm here to talk about. I'm from G Research. I work for our open source team. We're not a security research company. We're a quantitative research company and we predict things. So we use a lot of machine learning, AI. But we also use a lot of infrastructure underneath that. So our open source team aims to improve the infrastructure we use. We contribute some projects on top of that infrastructure. We use things like Kubernetes. But we also use terminals. And that's what I'm here to talk about today. So what is a terminal? Well, first of all, we need to go back in time. So we're going to go back to the 1960s. And what are terminals built on? ASCII, American Standard Code for Information Interchange. We've all heard of it. Do we know it that well? Probably maybe there's some strange things in it that are legacy. We take it for granted. This very slide has ASCII on it. To give it its full name, American Standards Association X3.4-1963. That looks like this. So this is the ASCII Standard Code. Now, if you look closely at this, it's got seven bits. It's got this large unassigned range. It's got an escape. That's what a lot of this talk is about. There's also something called WRU, which is who are you. And that's a way of asking the terminal on the other end what it is. And a lot of this talk will talk about that. So from the early days of the ASCII Standard, replies were something that were a key part of it. So in this case, you sent a single character, WRU, and in response, the other end would probably respond with RU. It turns out that this is actually a bit vague, because later on ASCII changed, and in 1967, they added, well, lower case, which was quite key. They also moved escape. So now, if you look closely at this table, all the control sequences are on the left two columns, except delete, which is actually an interesting legacy and one of those facts that I really like. Delete is where it is, because on a punch card, if you punch out all the holes, you delete a character. So sort of legacy things that we still have in ASCII, a design like that for a reason. It's one of those legacy things that doesn't hurt, but it's kind of amusing. So there's a few other details about ASCII. It only defined seven bits, as I said, although interestingly, two years after this in 1969, Vinsurf wrote RFC 20, and that basically said that the internet should use ASCII, but it also said that it should use 8-bit characters, which is what we expect these days, but that RFC actually defines that the 8-bit should just always be zero, so they hadn't yet actually defined what the 8-bit was, but they were leaving room for expansion. So there's a lot of sort of history here, and if you're interested in character A encodings, there's some references for this talk. There's books on it. IBM were very involved in it and some other things. So 60 years ago, there were some proposals on escape. So before ASCII was even officially published as a standard, Bob Bemmer, who was an employer of IBM, wrote an article in communications with the ACM called A Proposal for Character Code Compatibility, which is a bit of a wordy thing, but basically it was saying, we've got this single character set, but what are we going to do if we need to put international characters in and so on? And that was where escape was defined as a mechanism that allowed basically to say something different is coming after this point. And, you know, everyone here who's done freaking or anything knows how great in-band signalling is. So basically this is in-band signalling. And so the second reference is from 1963, and that was written by someone at AT&T, you know. So they really loved in-band signalling. And so this was a proposed discipline for the use of escape. And this was kind of the first time that what escape might mean was defined. And it's very interesting to sort of go back in the history of this. And one of the key things it actually defines is not what escape does, but how it is parsed, essentially. And so it says that particular letters or symbols after escape will either continue the escape sequence or end it. And that later becomes relevant. So what was ASCII actually used it? So in 1963, the teletype Model 33 was released. And this was one of the first devices to use ASCII. It's kind of lost a history of exactly what was using it. But, you know, this was a thing you could type into and it was used in the development of UNIX. So sitting down here, this is 1972, Ken Thompson is sitting down and Dennis Ritchie is standing up. Ken is sitting at a teletype writer or a TTY. So this UNIX machine has two TTYs. You know, we still call them TTYs, but they're not that device anymore. They're something quite different. But this is where terminals started. So in 1976, Lea Siegla released the ADM3A. Now this wasn't the first glass terminal. That was released by Datapoint in the early 70s. But this was one of the first affordable terminals, at least for the time in kit form. It cost under a thousand US dollars. And the University of California, Berkeley, standardised on these for various uses. And Bill Joy had one of these. And if we look closely at the keyboard, on the very left hand side are the configuration options. So you open a panel and change dip switches to adjust the speed and other things like that. But if you look very closely at the H, J, K and L keys, you say they've got arrows, then if you're a VIM user, you might be familiar with what those do. So this terminal was used by Bill Joy in the development of the X editor, which had a mode called VI. And as we all know, the rest is history. So this was the first device that was used to develop the visual editor that we now know on Unix. And there's another Unix reference here. If you look at the top right hand side, the home button has a tilde on it. And that's obviously what the home directory is these days. Exactly whether this is the exact reason that that is the case, people think so, but it's kind of lost in time. But yeah, there's definitely a lot of Unix history here. But why is this also interesting? Well, this was also one of the first terminals that let you position the cursor anywhere on the screen. This is from the manual, which someone has kindly preserved. And it basically says that the escape key can be used in conjunction with character keys to position the cursor anywhere on the screen. So rather than just moving the cursor up and down, you can say, I want it five rows down to across whatever it is, which lets you essentially implement any kind of editor or a visual application, at least as far as you can go visually in a terminal. And this was one of the first devices to support this kind of thing. Some of the earlier terminals only sported moving up and down, so it was more inefficient, especially over at the time people were using 300 board modems to talk to things. So if you imagine you have to send multiple characters to move the cursor around, you can literally see the cursor move. So the interesting thing in this document is actually somewhere in the middle. It says this operation may also be initiated by the host computer. So the user can type this as an escape sequence or the computer can basically say, position this where I want it on the screen. And basically that makes VI possible. So in 1978 the VT100 was released and this was really continuing the introduction of more and more features into terminals. But the interesting thing about the VT100 is it was one of the first terminals to implement this standard, which is known as X3.64-1979. But many people know this simply as ANSI. So we'll get to what that means. But to give it its full name, additional controls for use with American National Standard Code for Information Interchange. So basically this was, as I said earlier, there was a working group on Escape. That working group turned into this standard. There were some other details along the way, but this was the final product. The standard was actually released in 1979. So the VT100 was built in development of that standard and DEC actually released it before the standard was released. So very close together development. I haven't looked that closely at the history there, but it's quite interesting. But what does a VT100 give us? So it gives us escape sequences like this. So I'm using C-style strings here, so slash E is the escape character, and then the other things you see are just the symbols you expect them to be. So like I said, a particular sequence is defined. So here the left bracket opens a particular kind of escape sequence. Then you can have numbers, semicolons, and then usually a letter ends the sequence. So here the top one sets the top and bottom margins, which is a DEC specific one based on the name. The bottom two are positioning the cursor, and those are ANSI standard ones. They don't have a DEC prefix to the name. So we can actually just demo this. So like on a VT100 emulator, we can just, in a command line, we can run printf, and this will do something Sorry, this bit is not. So I'm actually using OpenBSD to demo this. So here I am just logging in as root as you do. But a console is a VT100 emulator, and here I can just type printf, and I've now limited myself to the top 10 lines of the screen. So if I type clear, you can now see I'm still hitting enter, but I don't go further down the screen. But I can use an escape sequence to move further down the screen. So I've now moved myself outside that restricted region using the DEC escape sequence. Now I can move 2,000 lines up. So OpenBSD just rebooted when I moved 2,000 lines down then. So what just happened? So have you tried forcing an unexpected reboot? So that was a present day OpenBSD bug. It resulted in this reliability fix in early 2023, and I found that basically the VT100 emulation, which was originally written for NetBSD in 1998. I don't think anyone had ever really audited it, so basically, yeah, you asked it to move around the screen, and there was some kind of... It was basically just a bounds checking error, as it says there. I later found another bug, so there's a further reliability fix while I was writing this talk. It turns out also, if you look at those escape sequences, I said you can have numbers and semicolons and things. It turns out if you just send 4 gigabytes of semicolons, you overflowed something. Both of these will either cause a kernel panic or a reboot, depending on exactly how they're arranged. I don't believe they're exploitable further. I'm sure someone might prove me wrong, but I would expect that address randomisation and other recent additions to a kernel's limit and a lot of this. Also, on a 64-bit system, you're probably far enough away and you can't actually set a more than 32-bit parameter. So maybe a 32-bit system without any address randomisation might be exploitable. If you went back to when this code was written in 1998 and found this bug, it would probably be far more interesting than it is right now, but no one found it then, fortunately or unfortunately. It's interesting that this bug has existed in OpenBSD and NetBSD for 25 years. There you go. Let's go to the 1980s now. PCs. DOS 2.0 introduced a driver called ansi.sys. This is a screenshot from PCJS.org, which is an awesome web-based PC emulator. It actually is quite a faithful emulation of PCs. It's not just like trying to make sure that XX6 works. It really does have the IBM BIOS and some other things. So you can go there, type in those commands, and if you see at the bottom where I've typed CLS and piped it to more, that's actually something that is built into DOS. If you type CLS and it's not directly connected to the screen, then it will output the escape sequence. In this case, I've not actually rebooted the drive said to load ansi.sys, so this is the default DOS behaviour. You just see the escape character on the screen. If you do this on the PCJS emulator, you reboot, then it will actually run that code. So that's how that works. Unfortunately, I've mined a tech, and of course she's meaning this particular demo is not going to work. I was going to demo what happens with ansi.sys on a more recent DOS, so basically bulletin boards and things use ansi.sys, and it was kind of awesome. Combined with this particular IBM code page, this is IBM code page 437, so I mentioned that what ASCII is, but if we look at the second half of this, there's some custom characters, and these are the IBM PC characters, and these, combined with the escape sequences that the ansi.sys driver gives you, allows you to do part like this. This was taken from dreams of insanity bulletin board, the intro to it, and you can find this online on textfiles.com or other places. So how you can actually view this on a modern computer is you can actually use ICONF to convert from IBM code page 437, and then you can pipe it to PV, which is a command line tool that can do various pipe-like things on Unix, and in this case I'm asking it to slow down enough that it behaves like a 28K modem, and if you run that, unfortunately the demo is not working for reasons, but basically you'll see the output just below it, and what that actually looks like when you look at it in a raw form is something like this. So you can see the text is actually sort of here and here, but there's all these control characters here. So it's kind of hard if you actually just open this in an editor to see what it's doing, and that of course brings us to a potential attack. So there's something called ansi bombs. Now the ansi.sys driver had a special ability to redefine keys. So if you could write something to someone's screen, you could redefine keys. Now what I'm showing there is actually a still detected by some antiviruses. That is a real virus, and it basically says for particular keys, redefine them. So if you type this to the screen like it tells you to, you do type help.txt, which is for those who've forgotten how DOS works, that's the same as cat to the screen basically. So raw cat is a bad idea, raw type is a bad idea on DOS a long time ago. So anyway, you do that, and then you hit enter, and what that actually expands to is a dow tree. So if we just go back, each one of these, the first sort of part of the sequence is which character to redefine. Sorry, I'm just... Sorry about that. So that's which character to redefine. And if we go right back to the ansi table, which I won't do right now, but you'll see that my favourite one here is... So 27 is escape. We'll talk about that a bit later. Eight is a good one, that's backspace. So you think you've made a mistake, and then you press backspace, and basically this is a prank. Bombs are always a prank. But anyway, it redefines certain keys if you cat this to your screen, and maybe you don't immediately realise this. There were many different variants of this. Some were sort of weird, and you maybe didn't even touch that key, so you didn't know it happened, and then later on you randomly press it. So this wasn't really considered a real security thing back in the day, but it's kind of amusing, because it's a predecessor to some of the things I'm going to get to. So yeah, probably bad deleting your C drive. And this worked, as you can see here, this was on DOS 622, I demoed this, but it worked all the way back to DOS 2 if you loaded the ANSI Sys Driver, which not everyone did, and there were also secure versions of the ANSI Sys Driver, but obviously this was the 90s and the 80s, so CVEs weren't really a thing, and stuff like that. So, you know, some of these attacks that I'm talking about are older than you may realise. So let's go to the 90s. So this was from FRAC in 1994, and it's a utility called flash.c. And so it says here, it's intended to quickly mess up a user's terminal by issuing a talk request and sending special characters, and it says it's really nasty. So let's have a look at what that actually is. So it sends these evil strings, so I won't go into exactly what they all do, but one of the ones that I mentioned earlier, and was the limiting to the top 10 lines of the screen. Well, this is limiting you to the top three lines of the screen, so already that's quite annoying, because you've got a really large terminal and you can only see three lines. It also inverts the background colour. One of them is a deck specific sequence that sends a test pattern to the screen, which basically means it fills the screen with ease. So, yeah. But just a quicker side, this, you see that says slash 033. So that's octal, so 033 is actually 27 in character numbers in decimal. So there are many ways to represent escape. I've already in this presentation shown free at the top, but you can also use JSON and Stockstalk mentioned that you probably should escape certain output to the screen using that. So, yeah, you can do that in JSON. If you're writing stuff in Go, then it doesn't do C-style string, so slash x1b, and in some cases just slash 27, and we'll get to some other variants on this in a moment. But yeah, so if you see this in various different forms, just be aware that there are many ways to represent escape. So, hello Defconn. This is a VT520. My dog also says hi. So, November 1995, this was released. Now, Windows 95 was obviously released before this, so this was new-ish tech for the time. It did some fancy things, but in the terminal world it was new. In the real computer world, most people are actually using X terms, and if we go back to this flash.c it says in the middle that it's actually expecting to target an X term. But let's just be time-appropriate here. So, what happens if we simulate receiving flash.c terminal DOS attack? I'm just going to have to switch inputs. This is going to be a bit crazy, because I thought I had this video copy, but I don't. Sorry, this flickers both because the video recording of this is kind of bad, but also there's an issue of the projector. But what happens is the screen goes blank anyway. So, this is kind of annoying. So if you send this to a real terminal, a reboot of it takes several seconds, so you literally send escape and see, and a real terminal breaks. If we remove the escape and see, and we send that, then we see roughly what we would have seen in X term or another terminal. So it starts flashing a lot and inverts the background. And now when we start typing, we also see our characters are not the normal characters. So there's a special alphabet that is designed for box drawing and things, a bit like we saw the PC had its own. So, yeah, we then went and reset, and we can see what happened. But notice reset didn't reset the fact that the screen was inverted. So this really messed up your terminal, send these things to the terminal, and it's kind of broken. So, yeah. So, let's go to 2003. So HD Moor did some research and published this article in bug track and poor disclosure at the time. Terminal emulator security issues. And now this is some of the first proper research. CVEs were still relatively new at the time. That's in quotes because it was rather CVEs. It was actually CANs. It's just going to go blank for a second. So these were CANs, and they later became CVEs. Is that going to come back? Let me just type XR on our commands for a moment. So, yeah. So this was among the first published CVEs. And so one of the ones in here is about window title reporting. So I've mentioned this in some previous talks. Sorry if you've seen that before, but I think it's important to repeat some of this. So what does this look like? So if we print something to the screen, like I showed before, you can print escape sequences to change positions on the screen and move things around. This is a special escape sequence to set the title. So your shell prompts will often include the command to set the title, for example. So what happens if we set it to CalchiXE? Well, that's not bad. But some terminals have a special sequence to ask for a reply of what the title is. So you ask for what the title is, it replies with what the title is. And so then this looks something a bit like this. Which one are we doing? This one. So, yeah, so we do something like this and CalchiXE opens back here. So it's literally that simple. But, yeah. So this is interesting. This wasn't an old vulnerability. I just ran that against ConyMU, which is a Windows terminal. So that vulnerability from Xterm also exists on ConyMU, and Swiftterm, and Westterm. The ConyMU is the most concerning, though, because actually what I did back here, if you look closely, is that I'm going to press enter slash X0D, which is also known as carried return. So in this case, I didn't have to press enter. The terminal pressed enter for me. That makes these attacks much more scary. It's either before you had to social engineer the user and pressing enter somehow, but it turns out, actually you don't always have to do that. So there are other ways to deliver this. I use printf. A user running printf is a bit like someone in a JavaScript console. Ask them to open the JavaScript console and attack themselves. But you can run curl on things. Curl is just like cutting something to the screen. So here I have an evil example.com, that when you query it and get it with curl, it says I am good. You pipe it to shell and it says I am evil. Down at the bottom, I've piped it to cat minus V, so you can see what's happening. Actually there's a comment and then a lot of backspace characters. So basically what you see is I am good when you cat it, but what the shell sees is I am evil followed by a comment. So you can basically make the user run one, see that they're going to run one thing and then run something different. This is actually kind of interesting because some recent attacks in the past year were called Trojan source where people used Unicode to achieve similar effects in text editors. So these kind of things have been possible in basically anywhere you have text. Sometimes text is not just pure ascii. There are other things in it, escape characters, Unicode, right to left, overrides, other things. So these things can apply in various ways. So cat minus V is considered good. In the 80s, the original Unix people from Bell Labs wrote an article called cat minus V considered harmful that cat shouldn't have any command line options and it should be its own thing, which is kind of amusing. But cat minus V is a good idea. Anything that can potentially write raw text to your terminal is harmful, so you can pipe it to cat minus V and see what's happening. Alternatively, the program itself, if it expects to print to a terminal, should just do the escaping itself. So if you use curl, what else can we do? Well it's always DNS, isn't it? This is a bit crazy, but it turns out you can put lots of things in DNS. So the easy place to do this is text records. I can put stuff in text records. But it turns out I can also, in many cases, put funny characters just in the host name itself. The interesting thing about that is depending what libc you're running, it may or may not resolve. So what I'm sort of proposing is a slightly crazy delivery method here is someone finds out that they can't access this host, but someone else says they can. So they start debugging it. And it turns out that on Alpine you can ping the relevant host because it does follow the C name chain to the crazy thing. But glibc doesn't. Actually, due to an unrelated vulnerability, I actually made OpenBSD change their behaviour. So OpenBSD older versions for about 7.3. Newer versions, it doesn't. You can also use this to tell the difference between macOS and Windows, potentially. So I reckon there's some fun things there. Anyway, that's kind of an aside. So what can we do with this? So Windows terminal, it turns out, supports some kind of music thing. So, yeah. Let's see if we can make this work. I just... I'm not going to work because I don't have any sound. Yeah, okay. So, yeah. Because I've changed the device here, that sound output is not going to work. But anyway, so you run that in Windows, and it turns out it starts playing music here. Which is kind of fun. But what did I just actually show you? Well, I showed you that if you run NSLookup, then it actually just writes raw things to the screen. So it turns out that this is a bug. So, for example, you have a bug in a tool called Commander, which actually is based on ConyMU that I just spoke about. So here we are. We just do an NSLookup on ConyMU.Lab. So, yeah. The interesting thing about this is... The interesting thing about this is I previously disclosed this as a bug. But actually this still works on the fixed version. I had a bit of discussion with the author of ConyMU about this. But if you look very closely, I'm using control O here, rather than pressing enter. So it turns out what the author did to fix this originally was look for carriage return and line feed. But it turns out if you're using a read line compatible shell, and this is Commander, which adds a bunch of Unix tools to Windows, and basically it's... Yeah, it runs... When you press control O, it actually is bound to a history add and accept, which is the same as pressing enter as far as anything is concerned. So, yeah, that's a thing. So... Sorry, I'm going to have to speed up slightly because we've got a few more of those to come. So we're not done with DNS. It turns out there are other tricks you can play with DNS. So... Apple terminal is actually relatively secure. I looked at it for a while and didn't find anything. But it does have a way of setting what your working directory is. So the way this works is the same way that I said that a title integrates with your shell prompt. You also integrate with your shell prompt and send the terminal a hidden escape sequence that tells it what working directory you're currently in. Which is, you know, that makes sense. It's useful to tell your working directory you're in because it turns out up here you have a thing that tells you that you're in either the temp or your home directory. And it gives you a pretty icon of your home if you're in your home directory. Anyway, if you actually read what's happening on the slide here, so I can print users DGL. First of all, that works fine. I can also, it turns out, put a host name in the file URL. And over here, on that file URL. So it's not like the end of the world, but it's an information leakage thing in that if I for some reason connected to a server that maybe doesn't have access to the outside world but the computer that I'm connecting from does, some malicious thing on that server could write something to my terminal and then it could actually through DNS tunnel it back to wherever. So you can use DNS as an actual exfiltration method via the terminal that some user is connected via. So I reported this to Apple in, as you can see here, October 2022. And I unfortunately haven't fixed it yet. So they're quite past the disclosure deadline for this one. It still works as far as I'm aware. I haven't tested the very latest version. But it turns out there's also another bug, which is kind of fun. If you actually get to about 1024 character somewhere around there, when you open a new tab, what it tries to do is change into that directory. And this sort of CD command you see on screen here is what it wrote. So it does that sort of for you. It turns out if it's longer than the allowed directory name length on macOS then it just hangs the entire terminal. So it's kind of a bit like a sleeping time bomb in that if you run that then the terminal time someone opens a new tab will just hang and they won't actually know why. The one saving grace there is if this actually is integrated for your prompt, the next time the prompt is displayed it will clear that and then it won't work. So it's not the end of the world. So back in HDMor's paper in 2003 there was a fictitious case study and it spoke about Apache locks. What's more relevant today? So developers run things like python free HTTP command lines. And if you saw stocks talk I'm afraid this is basically the same demo. But which one are we on? There we go. So we've got an attacker down here and a victim up the top. We can't put escape characters in via just using curl, but if we write raw to the screen sorry the screen, if we write using netcat we can write things and it turned out python didn't escape the log file. So we can change the colour of the logs. That's kind of fun. So it turns out if we've got a terminal vulnerability we can do things with that as well. This is item 2. The vulnerability was that it would reply with a user controllable string. So what it's supposed to be used for is querying the colour. So here it's telling us that the colour is 31M red. I just changed the colour back to the default colour and it says it's 0. But it turns out if we put something else there then it replies up here with something else. And it turns out that can be anything else. So the real insight is that we can put control C there. So by putting control C there it will basically kill python. And at that point we can run anything we want in the terminal. So we put control C. Because of how this works in item 2 we kind of have to split each control character into its own escape sequence. But it turns out python just doesn't care what the HTTP request looks like. So we can just really put any characters we feel like in the request thing and eventually calculator pops up. So that was a bug in item 2 that was fixed. And as I mentioned the request selection or setting which is a depth specific escape sequence was used for querying the color and thing. There was an implementation bug in that. And it unexpectedly echoed a string back. Control C is also a part of a string. So we can press control C. And I call this a full echo back. So how about another one? So this is the git for windows. Also known as git bash. So here we're cloning a git repository. We're going to this git repository. We run git log. So what does git log normally do? Git log opens calculator today. So if we pipe that to cat minus v we'll see up here it says just below is an escape sequence or own you and that's actually in the commit log of this git repository. And it's also a cross platform exploit as you might notice because this is actually the same bug as the item 2.1. It's a new user. So this is a tool that you can use to access. And it turned out on windows was vulnerable to this. So yeah, sorry, slides loading slowly here. But we'll get there. So yeah. So git uses less as a pager and less had a bug in it's OSC 8 handling. Mae'n dda i dda i ddim yn mynd i lles a ddim yn y terminol. Dwi'n d din i ddim yn shawdd i wneud gyda'i gyda am y byddau mynd i ddim yn gyd, ac mae'n ddim ddim yn mynd i ddim yn mynd i chyfnodol cyfwylo gyda lles. mae'n ddim yn mynd i ddim yn mynd i chyfnodol cyfwylo. Dyna nhw yn ddim yn mynd iddynt, rydyn ni'n ddim yn lleu doennwyd o'ch byddag teithio, mae'n ddim yn mynd i'n ddim yn lles i ddim yn mynd i'n meddwl geistrae. Felly, here, this ended it as far as Mintity was concerned, but it didn't end the escape sequence inside the OSC8 as far as Les was concerned. The funny thing about this is, this bug was disclosed earlier this year. In the posting of it, I sort of said it was a denial of service attack and then later on I worked out actually, this can also be used for a bit more when I found a terminal exploit. I don't know if anyone else noticed that, but anyway, so we're getting a bit long time, so I'm going to run it a little bit faster here. So basically this deck RQS thing I showed was actually an external bug, and it's funny because it was documented incorrectly in the external manual of control sequences, and then various other terminals have recreated similar bugs. So let's just go to a slightly different thing. So we've got a shared system. Administrator gets an alert about excessive memory usage, starts debugging. What command do you run? Top, someone said. Good. So what if there was a bug in top? Which video is it? That one. So here I've got top, oops, that went too quickly. Anyway, I've got a script running on the, sorry, we'll try that again. I've got how short this video was. So here we're running top minus capital O, sorry, minus O, capital res, and on the left-hand side we've got a little script running. And what just happened? Well, you got owned. So it turns out this is an external bug in its optional graphic support. So basically we can do something like this. So we can get escape sequences into top. Regis is a particular graphics thing that digital invented in the 80s, and some of their terminals supported this. So if you tell X term to run in compatibility mode of one of those terminals, and then you print some special sequence, it replies with something like A1 equals XXX, and the exploit essentially is you can build up a, you don't get very many characters, but you can build up an environment variable if you run about 10 different processes. So it's a bit obscure. The X term Regis support isn't default. Some distributions enable it, hello NixOS. But top 3.X doesn't do escaping. 4.X does. Very few distros have it. I failed to convince the top authors that this is a security problem. As far as they're concerned, there are other ways to spoof things in top. So it's actually the terminals problem. And this can also be used as a docker escape. So if you're running as the administrator outside docker and you run top, you still see processes inside docker. So potentially there are other avenues to this. But we can also attack Kubernetes here. So let's have a look at Windows terminal. So this is Windows terminal. Here I'm just running busybox and deliberately running this as a nobody user. So this is, you know, not, no special privileges here. But there is this interesting file called termination log. And so if we write an exploit to termination log, and then actually we just exit, for whatever reason, this container has just died. So the administrator starts debugging what's happening here. So how do you debug Kubernetes? You run kubectl. So there's this pod running. It's just said it's restarted. So maybe the administrator got an alert, it restarted or something. So the first thing you run is kubectl describe that pod. And then nothing really happens. There's no message, which is a bit strange. But yeah, the victim over here doesn't really know what's happening. They start debugging a bit more. So they decide that they're going to duplicate this tab so they can have more context. So this was, I'm going to skip that one. So that was a Windows terminal bug. But what can we do with documented escape characters? Well, it turns out there are certain replies that do interesting things. So if, for example, we ask what color something is, colors in some terminals are separated with slashes. And where can we find lack of escaping? So we can create, put files on disk and see if things do that. Turns out NMCLI on Linux, if we happen to connect to a wireless network with an escape character in it, will happily, I've got a network at home called Red. It was actually the color Red. Bluetooth CTL on Linux mostly doesn't escape things. Some of these are hard to exploit. You don't get very many characters. But like I showed at the top, you could maybe create lots and lots of devices or networks or something. And, you know, comment forms on website. See stocks talk for more on that. But let's have a quick demo. I'm running out of time, so I'm going a little bit faster than expected here. But here I've got a script that sets up a particular thing in slash TMP. And so now I'm just typing CD slash TMP. And I hit tap like you often do, right, to see what's existing in that directory. So when I hit tap, what happened? My cursor disappears. That's strange. So I'm not sure what happens. I press control C and then I hit enter and everything goes red and it all gets a bit broken. So what just happened there? So the slides for this will be up later. I'm going to skip this quickly. But basically you hide the cursor, you ask what colour it is, and because you're in a control directory slash TMP, you created a file that the shell printed out on screen and basically, magically, the user basically has to hit enter. You make it, there's a scape sequence for X term that makes it so control C, just writes some escape characters to the screen. So there's literally nothing you can do except close the terminal or press enter. So you're social engineer, the user into, they probably press enter because they think their terminal is broken. So how do you protect yourself from all this? So terminals are just like a browser. They deal with untrusted input. Ensure correct output escaping, see this talk, stock talk. Secure settings. That's a fun one. If you use itone 2, just go and turn this on right now unless you actually use the shell integration features that might be bugs there. Who knows? Also ST is a cool terminal. You should use it. It's like really basic. If you don't actually want the features your terminal gives you, then you limit your exposure by using basic things. There's probably some end days here. So I'm crazy and if you've got a phone or something, try a sage into that particular IP address. It's on the Defcon network. It will test your terminal. And I want to make this repository public. How many buttons do you have to press to do that? Really? Anyway, so I just published that. In writing that tool I found another bug. That's all the bugs I found. Thank you very much.