[HN Gopher] Git: Malicious repositories can execute remote code ...
___________________________________________________________________
Git: Malicious repositories can execute remote code while cloning
Author : todsacerdoti
Score : 90 points
Date : 2021-03-09 21:52 UTC (1 hours ago)
(HTM) web link (www.openwall.com)
(TXT) w3m dump (www.openwall.com)
| jolmg wrote:
| > This vulnerability affects platforms with case-insensitive
| filesystems...
|
| What kind of platforms use case-insensitive filesystems?
| Operyl wrote:
| macOS, to name one. It appears NTFS is also vulnerable
| according to the posting.
| jnwatson wrote:
| FYI, on MacOS, it is a property of the partition, so you can
| reformat and have a case-sensitive filesystem. Applications
| may subtly break if they weren't tested on such a filesystem,
| but I had used one for several years without too many issues.
| pcthrowaway wrote:
| Ashamed to admit (as an OSX user) that I didn't even realize
| the FS was case-insensitive (having migrated from years of
| Linux usage to a non-Linux desktop). It does a good job of
| hiding this from the user (filenames are still listed with
| cases, and bash autocompletion completes to the correct case
| as well)
| Cloudef wrote:
| OSX has even more annoying problem that it decomposes
| unicode: https://stackoverflow.com/questions/5581857/git-
| and-the-umla...
|
| Many fun times trying to copy/move/remove a file and not
| being able to do so because the input and name stored on fs
| is actually different bytewise...
|
| Seems like linux has the only sane filesystems not trying
| to mangle paths at all.
| jrochkind1 wrote:
| If linux doesn't normalize unicode at all, can you have
| two different files that look like they are named `jose`,
| depending on if the e is decomposed or not?
| caymanjim wrote:
| MacOS by default uses a "case-preserving case-insensitive"
| filesystem, so you can create files with mixed case, but
| you can't create two files with the same name and different
| case. It's one of MacOS's more-egregious crimes against
| Unix. Fortunately it doesn't manifest that often, but it
| rears its head often enough to be a problem.
| leephillips wrote:
| It may be a crime, but is the result of a set of
| compromises in the design of the OSX filesystem, which
| had to work with a BSD variant while also being
| compatible with pre-OSX days. I think it's one thing they
| actually did an elegant job with.
| _jal wrote:
| > It's one of MacOS's more-egregious crimes against Unix.
|
| Nah. Using a file system means putting up with its
| semantics. HFS+ was case-insensitive; they were deploying
| an upgrade to millions of existing filesystems.
|
| If you mount, say, an NFS volume, MacOS does the expected
| thing.
| ComputerGuru wrote:
| That's the same as Windows, but Windows enables making
| directories case sensitive on a directory by directory
| basis.
| [deleted]
| [deleted]
| oars wrote:
| I'm in the same boat - used MacOS for the past 6 years,
| including the terminal nearly everyday! :d
| [deleted]
| rhinoceraptor wrote:
| MacOS and Windows
| jolmg wrote:
| I guess it shows that I haven't really used either of those
| in a long time.
| Jtsummers wrote:
| macOS has defaulted to be case insensitive largely due to
| historical and perhaps usability reasons. You can opt to
| make it case sensitive (and I do, which broke Steam for
| several years but that also freed my time).
| cma wrote:
| In windows, the underlying ntfs is still case sensitive, and
| that gets made use of with the WSL 1.0 stuff.
| [deleted]
| [deleted]
| zo1 wrote:
| Windows.
|
| Its a notable problem with git + Windows that has gotten better
| over time but still leads to a lot of WTF moments. For many
| this event is the _first time_ they hear that window 's
| filesystem is case insensitive.
| rightbyte wrote:
| It is strange I haven't noticed earlier. Maybe it is just so
| unnatural to name files the same with different cases that I
| haven't tried.
| Foxboron wrote:
| Linux these days actually. You can make ext4 case insesitive.
|
| https://www.collabora.com/news-and-blog/blog/2020/08/27/usin...
|
| Note: I also learned this today. Had no clue.
| floatingatoll wrote:
| > if Git is configured globally to apply delay-capable
| clean/smudge filters (such as Git LFS)
|
| What is the simple test for whether this is the case or not?
|
| Is this a default-on scenario?
| goatinaboat wrote:
| _Is this a default-on scenario?_
|
| No, LFS is something you would have to explicitly enable,
| however it is pretty common to do so if you want to store
| binary blobs in Git.
| amelius wrote:
| Ok, but malicious repositories can do a lot of bad things after
| cloning. So I guess this warning is relevant only to people who
| wish to inspect the code before running.
| marcosdumay wrote:
| If you can't clone and then verify the code, a lot of things
| get much harder.
| stefan_ wrote:
| The commit that fixes this issue:
|
| https://github.com/gitster/git/commit/684dd4c2b414bcf648505e...
|
| (Surprise, the root cause is a _cache_ )
| softwaredoug wrote:
| Another cachelty
| segfaultbuserr wrote:
| Difficult problems in programming:
|
| (1) cache invalidation
|
| (2) off-by-one errors
| mattiasfestin wrote:
| The classical three problems.
| f430 wrote:
| clicking on openwall.com is blocked ... weird
___________________________________________________________________
(page generated 2021-03-09 23:00 UTC)