Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git security vulnerabilities announced

github.blog

Post reply on HN
Print view View original

111–120 of 139 posts

Re: Git security vulnerabilities announced

#111

Post by [deleted] »

tomxor wrote: post #100
adrianmonk wrote: post #65

Earlier quoted context omitted.

> git 2.39.1 is already available on Ubuntu The updater just gave me 1:2.37.2-1ubuntu1.2 (to replace 1:2.37.2-1ubuntu1.1). It said it addresses the two CVEs in question. So they (Ubuntu or maybe Debian) are taking the approach of patching a slightly older git version.

I'm not sure why they aren't bumping the patch number, maybe they decided against applying the other parts of the patch for least change - but at least the CVEs are mentioned in all of the Ubuntu changelogs. I can't find anything in the Debian changelogs referring to the CVEs. Yet the Ubuntu changelog refers to it as a debian patch... Anyone know anything about Debian?

[deleted]

Re: Git security vulnerabilities announced

#112

Post by kibwen »

p4l4g4 wrote: post #49
kibwen wrote: post #25

Earlier quoted context omitted.

Furthermore, because integer overflow is defined behavior, the integer overflow is never considered a root cause in Rust. In order for an integer overflow to express as UB in Rust, you'd have to use it in conjunction with an `unsafe` block that was failing to ensure its invariants, and that would be considered the root cause. If you're not using `unsafe`, then an integer overflow is at worst a logic bug.

A logic bug can be dangerous too though. E.g. Bumping a user ID, to get a "fresh" one or calculate port to open based on offset. When not bounded to a known range, this kind of logic can easily pose a serious security risk. Most of the time, it will probably just work, but under extreme conditions, it will fail. If your language at least catch the overflow and crash instead of wrapping around, you "only" have a denia…

Indeed, nobody ever said that logic bugs were good, but as a category of flaw it means that integer overflow in Rust isn't particularly interesting compared to all the other innumerable ways to introduce logic bugs. And I say that as someone who wouldn't really mind if the behavior was changed to panic-by-default in release mode.

Re: Git security vulnerabilities announced

#114

Post by hot_gril »

bbojan wrote: post #3

Both critical bugs are integer overflows. It's unclear to me why our languages still default to modulo arithmetic semantics. I feel Rust had a chance to fix this, but also dropped the ball.

The funniest is how Solidity does this. The language focused on transfers of money.

Re: Git security vulnerabilities announced

#115

Post by hot_gril »

xxpor wrote: post #4
bbojan wrote: post #3

Both critical bugs are integer overflows. It's unclear to me why our languages still default to modulo arithmetic semantics. I feel Rust had a chance to fix this, but also dropped the ball.

>It's unclear to me why our languages still default to modulo arithmetic semantics. Because that's what processors do? (leaving aside backwards compatibility issues)

Processors also emit a signal when there's an over/underflow. Is it costly to check that at a low level and terminate the process in this case?

Re: Git security vulnerabilities announced

#116

Post by hot_gril »

dcsommer wrote: post #50
IncRnd wrote: post #41

Earlier quoted context omitted.

> Integer overflow isn't a security issue unless your program's memory safety depends on the correctness of the integer operation. That's simply not true and has wide-reaching horrible effects that can occur. The wrong number of tickets can be purchased from a website, charging for less than were purchased. The DNR order can be put in place instead of SAVE LIFE. There are countless security issues that can occur. Say…

Do you have data on the relative frequency and severity of non-memory safety integer overflow security issues?

I know at least about the DAO hack.

Re: Git security vulnerabilities announced

#117

Post by saurik »

tomesco wrote: post #96

What is the recommended upgrade path for macOS' system install of git? I have upgraded my brew install, but am unsure of what to do with the vulnerable system install.

I don't think macOS comes with git; like, it might actually come with a git binary, but that binary is just a "shim" that runs an actual copy of git from an installed copy of Xcode. If you want to upgrade what is conceptually that copy of git you can thereby upgrade Xcode. (If you haven't installed Xcode then it might have come from a related package called Xcode Command Line Tools that doesn't include Xcode.app; if you run these shims and don't have Xcode installed it offers to install this package for you automatically.)

Re: Git security vulnerabilities announced

#118

Post by foresto »

tomxor wrote: post #100
adrianmonk wrote: post #65

Earlier quoted context omitted.

> git 2.39.1 is already available on Ubuntu The updater just gave me 1:2.37.2-1ubuntu1.2 (to replace 1:2.37.2-1ubuntu1.1). It said it addresses the two CVEs in question. So they (Ubuntu or maybe Debian) are taking the approach of patching a slightly older git version.

I'm not sure why they aren't bumping the patch number, maybe they decided against applying the other parts of the patch for least change - but at least the CVEs are mentioned in all of the Ubuntu changelogs. I can't find anything in the Debian changelogs referring to the CVEs. Yet the Ubuntu changelog refers to it as a debian patch... Anyone know anything about Debian?

Looks like it's tracked in Debian, but not addressed yet.

https://security-tracker.debian.org/tracker/CVE-2022-23521

https://security-tracker.debian.org/tracker/CVE-2022-41903

https://www.debian.org/security/2023/

https://tracker.debian.org/pkg/git

Re: Git security vulnerabilities announced

#119

Post by joe_guy »

jasonmarks_ wrote: post #106
codazoda wrote: post #87

I don't think Apple has patched this yet (it just came out 3 hours ago). Looks like homebrew got right on it so I installed via that with the following command. `brew install git` The latest version in Ventura 13.1 seems to be either 2.24.3 or 2.37.1 (not all my co-workers machines match). I'm not sure if these are defaults, different because some of us have XCode, or if some of us manually installed. In any case, br…

I too think package managers are amazing... reads new git security threat "brew upgrade" done!

Running brew upgrade uses git, so it has to run the insecure git to upgrade.

Re: Git security vulnerabilities announced

#120

Post by zerocrates »

Arnavion wrote: post #102
zerocrates wrote: post #95

Earlier quoted context omitted.

What I don't quite get is why there's spellchecking on incoming commits at all.

Don't understand what you mean by "incoming commits". git-gui shows you a textbox for the commit message, and error squiggles for misspelled words (presumably; I CBA to install a spell checker). The bug is that it spawns the spellcheck binary using Tcl's API, which on Windows also looks up binaries in the current directory regardless of whether the current directory is in $PATH or not. Edit: Maybe you're referring to…

My reason for asking that is that this is the vuln description from the article:

> After cloning a repository, Git GUI automatically applies some post-processing to the resulting checkout, including running a spell-checker, if one is available.

> A Windows-specific vulnerability causes Git GUI to look for the spell-check in the worktree that was just checked out, which may result in running untrusted code.

I get what you're saying that just in general, there's an issue that you could put a file that matches the name for the spellchecker command in the repo and thereby have git-gui run your payload when the spellchecker should run.

But the article says this is "post-processing" to a checkout. That's what doesn't make sense to me, but the CVE itself says the same thing, that aspell is getting run immediately after a clone. What's the point of doing that?

Post reply on HN