5 ms·
No, kitty does not let stdout out read or delete arbitrary files. First of all stdout is an integer in a lookup table in your kernel, It cant read or delete any
by aumerle 4y ago
No, kitty does not let stdout out read or delete arbitrary files. First of all stdout is an integer in a lookup table in your kernel, It cant read or delete anything. I assume you mean it lets programs read or delete arbitrary files by writing to and reading from the tty device. And even that is not true. The kitty graphics protocol does let a program delete arbitrary files in the TEMP directory. It does not let anyone either read or list the contents of any part of the filesystem.
- yencabulator 4y ago> First of all stdout is an integer in a lookup table in your kernel, It cant read or delete anything. Oh come on, you know what everyone means. "Output with potentially hostile content". Right now it seems kitty will happily delete e.g. /tmp/.X11-unix/X0. That sounds fun. https://sw.kovidgoyal.net/kitty/graphics-protocol/#the-transmission-medium https://sw.kovidgoyal.net/kitty/graphics-protocol/#the-trans... https://github.com/kovidgoyal/kitty/blob/5541e3c2ff441aea31940924ff952c968a77a30e/kitty/graphics.c#L423-L424 https://github.com/kovidgoyal/kitty/blob/5541e3c2ff441aea319...
- aumerle 4y agoEveryone?? No just you. And read the rest of my post. Yes, kitty will delete files in /tmp if asked to. That's what I said. And no unlike your claim, it does not read them. If you cannot tolerate the theoretical possibility of something deleting a file in /tmp ever, then set TEMP before you launch kitty to /tmp/my-mommy-told-me-not-to-put-valuable-things-in-tmp-but-i-didnt-listen
- yencabulator 4y agoHoly excessive combativeness, Batman! > And no unlike your claim, it does not read them. strace -e open,openat kitty printf '\e_Gf=24,s=10,v=20,t=f;%s\e\\' "$(echo -n /etc/passwd|base64)" openat(AT_FDCWD, "/etc/passwd", O_RDONLY|O_CLOEXEC) = 14
- aumerle 4y agoAre you being deliberately obtuse? Yes obviously when asked to display a file, kitty will read it. But it wont send the file contents on the TTY, so the *program sending the request* cannot read it. Which is what we are discussing here. You are trying to make it seem like the ability of a program to get kitty to read an arbitrary file is a security issue. I suggest you go do the following: strace your editor, then ask it to open /etc/passwd, and then be shocked when you see it doing so in the strace log. Seriously, why am I wasting time replying to you.
- yencabulator 4y agoI'm trying to make it seem like kitty doesn't have very strong security boundaries, and it's a bit of unknown what it can and cannot be made to do. Me asking my editor to open /etc/passwd is me asking my editor to do something. My terminal emulator opening files and parsing them and deleting them just because I viewed untrusted content is something different. If you want to make that argument, you need to come up with an example where my editor accesses attacker-controlled files because I opened a random README.md. Also, please read https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html, and shove your attitude.
- aumerle 4y agoAh so classic FUD, "its unknown what it can do". Why dont you spend some effort figuring out what it can actually do instead of making driveby comments with an obvious axe to grind. You very conveniently left out the fact that pretty much anything that views untrusted content has to parse files. If parsing files is where your "security boundaries" lie, I suggest you drop your computer off at the garbage dump. Hell if your editor has a preview function it too will parse untrusted content. Basically, to do anything software has to parse untrusted content. And just by the way, /etc/passwd is not attacker controlled. If the attacker has access to your filesystem already, she really doesnt need to use kitty to do anything. And "opening" README.md will not cause kitty to parse files, unless by "opening" you mean catting without -v. In which case we are back to your mommy told you to know better but you didn't listen. At this point its obvious you are deliberately trying to spread FUD. I am done interacting with you. Good bye.