Man who thought opening a TXT file is fine thought wrong • Hacker News Board

Re: Man who thought opening a TXT file is fine thought wrong

#261

Post by ryandrake » Sat, Apr 03, 2021, 4:10 PM UTC

rcrisan wrote: post #186

tmp538394722 wrote: post #136

Earlier quoted context omitted.

“Everything’s a file!”

perhaps this is the worst possible abstraction to be protected by a security framework.

I don't think "everything is a file" is necessarily bad. What's worse is "every application I run has access to every resource that the OS gives my user access to".

Would be nice if the operating system could set up a fresh, temporary "user" for each application installed, and instead run the application as that user, who starts out with no access to computing resources. Maybe some existing systems already sandbox apps into their own unprivileged users, I don't know, but it would probably be very secure.

Re: Man who thought opening a TXT file is fine thought wrong

#262

Post by 2ion » Sat, Apr 03, 2021, 4:13 PM UTC

> It seems TextEdit for some reason thought it should parse the HTML even while the file format was TXT. So we can inject a bunch of limited HTML into a text file, now what?

Well, what's a file type unless you know it from context, for example a special file system attribute that set to "text/html"? Heuristics. At the very least I think it's better to ignore file "extensions" completely when dealing with the data inside than to make it the deciding factor.

libmagic, which powers a lot of file(1)'s work, is called libmagic for several reasons.

Re: Man who thought opening a TXT file is fine thought wrong

#263

Post by zrobotics » Sat, Apr 03, 2021, 4:14 PM UTC

aruggirello wrote: post #233

dewlinedew2 wrote: post #76

Earlier quoted context omitted.

shoulda used 'cat

that wouldn't work nicely with the mouse :)

That's what the on-screen keyboard is for. Even works with the touchscreen, no mouse required! Eminently usable.

Re: Man who thought opening a TXT file is fine thought wrong

#264

Post by icedchai » Sat, Apr 03, 2021, 4:21 PM UTC

mceachen wrote: post #142

throwawayboise wrote: post #89

Earlier quoted context omitted.

TextEdit dates back to NeXTStep, so it was originally written in the late 1980s probably. Guessing it didn't render HTML originally, but it always had RTF capability. Not that it's an excuse in 2021, but very few applications from that era woudl be considered "safe" today.

An example of "unsafe defaults:" NeXT used Display PostScript for the display manager. If you opened an email that had PostScript commands, the mail agent would happily, automatically, execute them. A favorite payload sent around the computer lab would smear all pixels downward to "melt" whatever was rendered on your display. Note that there weren't that many interesting things to exfiltrate back then, so this wasn't…

You don't need a password to be echoed to exfiltrate it. You just need the key codes. Not sure about NeXTStep, but regular old X let you sniff keys really easily.

Some systems (specifically, earlier versions of SGI IRIX) shipped with X authorization disabled by default. This is the equivalent of "xhost +". You could sniff a box as soon as it was plugged into the network, including capturing login session credentials, all terminal commands, and anything else. When they su'd to root, yes, you'd capture the root password.

In those days (mid 90's) almost nobody was running firewalls. At least, nobody in these parts. Putting your "office on the Internet" meant raw, unfiltered IP.

Re: Man who thought opening a TXT file is fine thought wrong

#265

Post by soulofmischief » Sat, Apr 03, 2021, 4:24 PM UTC

rijoja wrote: post #253

amenod wrote: post #241

Earlier quoted context omitted.

For anyone wondering, it is enabled by default on Ubuntu too. I wonder what made someone think that this was a good idea?

If you follow the everything is a file philosophy it seems quite natural does it not?

Except permissions aren't granular enough / are too confusing, it's a giant footgun with the current Linux architecture, which doesn't have all the nice things Plan9 does

Re: Man who thought opening a TXT file is fine thought wrong

#266

Post by stjohnswarts » Sat, Apr 03, 2021, 4:27 PM UTC

Thorentis wrote: post #134

Meta comment: The custom scroll behaviour on that site is awful. I hate sites that try to "improve" the behaviour of scrolling by making it faster/slower than normal.

Ublock origin blocks it evidently.

Re: Man who thought opening a TXT file is fine thought wrong

#267

Post by stjohnswarts » Sat, Apr 03, 2021, 4:28 PM UTC

lupire wrote: post #93

Why is TextEdit accessing the Internet without permission? Does Big Sur's Access Control block stuff like this?

This is why I use vallum.

Re: Man who thought opening a TXT file is fine thought wrong

#268

Post by crazygringo » Sat, Apr 03, 2021, 4:52 PM UTC

bawolff wrote: post #145

crazygringo wrote: post #105

Oh, man. The idea that TextEdit automatically parsed .txt files as HTML if they started with a certain file signature is problematic... ...but the fact that file:// schemes can access remote files by appending /net/ followed by a domain name is pretty shocking. I mean, the entire purpose of "file://" would seem to be to provide access to local/mounted files and only those. The fact that a Mac engineer thought it woul…

> ...but the fact that file:// schemes can access remote files by appending /net/ followed by a domain name is pretty shocking. Not that shocking. Windows has had that with SMB networking for ages file://SMBSERVERNAME/path/file . Linux somewhat supports /dev/tcp/HOSTNAME/PORT (technically that's application level in bash so not everywhere), and im sure there's daemons you could run to automount things on the fly.

SMB is more understandable though, since you have more trust for things on your local network, and an attacker usually won't have control over those resources. And it's a fairly common and reasonable expectation in a business environment that network drives appear as part of the filesystem.

Whereas a domain name over the open internet is an entirely different story.

Re: Man who thought opening a TXT file is fine thought wrong

#269

Post by anaerobicover » Sat, Apr 03, 2021, 5:20 PM UTC

thought_alarm wrote: post #126

throwawayboise wrote: post #89

Earlier quoted context omitted.

TextEdit dates back to NeXTStep, so it was originally written in the late 1980s probably. Guessing it didn't render HTML originally, but it always had RTF capability. Not that it's an excuse in 2021, but very few applications from that era woudl be considered "safe" today.

Edit.app is the original NeXTSTEP text editor from the 1989. It supported plain text and rich text files. Famously, the first web browser was based on the rich text capabilities built into NeXSTEP. TextEdit.app is the OpenStep rewrite of Edit.app and dates to the mid 1990s. It was likely one of the first OpenStep apps. It supported the same rich text files as the original Edit.app. Apple bought NeXT, OpenStep became…

> Apple used to publish the source code for TextEdit as part of their Xcode sample code, but they stopped a few years ago.

The URL still works if you want it, but, yeah, it's obviously not up-to-date:

https://developer.apple.com/library/archive/samplecode/TextE...

> (then Swift, probably).

Not yet at least; there's no Swift symbols in the binary on Big Sur.

Re: Man who thought opening a TXT file is fine thought wrong

#270

Post by jaxn » Sat, Apr 03, 2021, 5:25 PM UTC

rualca wrote: post #255

jaxn wrote: post #137

Earlier quoted context omitted.

But is it reasonable to treat a .txt as anything other than plain text?

You should read the article before commenting. The blog post states that the contents of said "text file" were quite literally This is not a mere text file. At all. This is a HTML document that might be deemed valid by a very permissive validator. Just because HTML might be stored in a text file that does not mean that a noncompliant HTML file ceases to be a HTML file.

I read the article. I understand that. But what takes precedence, the first line or the extension.