Git security vulnerabilities announced (opens in new tab)

> Rust had a chance to fix this, but also dropped the ball.

By default, a Rust project will panic on integer overflow in debug builds and will overflow on release builds. Two key points to note, however:

1. You can change the setting so that your project panics in release or overflows in debug mode.

2. We reserved the right to change the default at some point in the future. This will probably be widely communicated before it ever happens, and last I heard we are still waiting for the cost of performing those checks to be "reasonable" before thinking about making such a change.

>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)

Rust does have a fix for this:

  error: this arithmetic operation will overflow
   --> src/main.rs:2:18
    |
  2 |     let a: u64 = u64::MAX + 1;
    |                  ^^^^^^^^^^^^ attempt to compute `u64::MAX + 1_u64`, which would overflow
    |
    = note: `#[deny(arithmetic_overflow)]` on by default

Rust also allows for overflowing arithmetic (preserving the default to fail):

https://doc.rust-lang.org/std/?search=overflowing

It's generally less ergonomic, e.g.

  let (zero, _did_overflow) = u64::MAX.overflowing_add(1);

Rust makes integer overflow panic in debug builds, so Rust code is effectively required to opt into overflowing operations for correctness reasons. It disables those checks on release builds for performance reasons, but as sibling comments point out, it reserves the right to change that behavior.

Unfortunately, there is a circular dependency here. Languages are reluctant to make integer overflows error conditions because there is a moderately high overhead to checking overflow conditions constantly, and processors (and compilers) are unwilling to make overflow checks cheaper because they benchmarks they care about don't do such checks.

I'm wondering if what you are asking for is what Swift does - overflow kills your program, but you can opt into allowing it by using "Overflow Operators" (&+, &- and &*).

This crashes in Swift

   var potentialOverflow = Int16.max
   potentialOverflow += 1

This does not crash

   var potentialOverflow = Int16.max
   potentialOverflow &+= 1

[1] https://docs.swift.org/swift-book/LanguageGuide/AdvancedOper...

I'm quite paranoid about integer overflows, so in my hobby projects I now have a habit of always using helper functions (which generate an error on overflow) instead of "bare" math operators, and whenever I see a bare math operator without any checks in an open source project (and from what I've seen almost no one checks for overflows) I wonder whether they thought about potential consequences or I'm being too paranoid

Because saturating math is not "more right", just "different wrong". The "right" way of checking an error condition after every integer operation is prohibitively expensive.

From the language side, what I wish for is a sort of NaN for integer operations. I would not want to check for overflow on every operation, but I would want to know after a couple of them if somewhere an overflow had occurred. On the hardware side this could be done with a sticky overflow bit, which some architectures already support.

I think the ball is on the hardware side and in my opinion Rust did the most sensible thing possible with contemporary hardware.

Integer overflow isn't a security issue unless your program's memory safety depends on the correctness of the integer operation. Safe rust doesn't (in any build mode), but C/C++ does.

> I feel Rust had a chance to fix this

Don't see how. Given the hardware Rust is designed to program you have to compromise some or all of efficiency, memory usage and complexity to solve overflow.

I wonder if using 64-bit integers all over the place would alleviate this a bit. If your integers represent some real quantities (sizes of objects, etc), the sizes have to be unrealistically huge to trigger an overflow. If your integer is a counter, it would take years to increment it in a tight loop to achieve an overflow.

The cost of operating on 64-bit integers is about the same as operating on 32-bit integers on most modern CPUs (except maybe 32-bit cores in MCUs).

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

> [Edit: According to @rlpb's comment, git 2.39.1 is already available on Ubuntu]

Note that I said Ubuntu's git package was updated, but didn't say to what version. Ubuntu like most stable distributions cherry-pick security fixes rather than bump major versions, so Ubuntu users will get a version with these vulnerabilities patched but not necessarily a bump up to 2.39.1. See https://ubuntu.com/security/notices/USN-5810-1 for details.

Ubuntu will update git, without having to add this.

> 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.

As stated in the advisory:

> It may also be triggered indirectly via Git’s export-subst mechanism, which applies the formatting modifiers to selected files when using git archive.

This very practical to exploit on Git forges like GitHub or GitLab which allow their users to download archives of tags or branches.

You could bury it in a script, or in one of the many "copy and paste this command into your terminal" blurbs that we see all over the place.

Pretty narrow vector. Could identify low level employee in another team to run it to exfiltrate info in a high secure env maybe.

> url = https://github.com/gitster/git

huh, I would have thought for sure they would have linked to git/git from which that repo was forked

Also, the 2.39.1 tag alleges it was created Dec 13th - I wonder why they held it so long? I would have thought maybe embargo but the actual commit says "security fix" https://github.com/git/git/commit/01443f01b7c6a3c6ef03268b64...

this should really be the article link instead of that proprietary writeup by a company taking advantage of OSS

edit: just because someone puts up an "easy" ""free"" service, does not mean they are kind. GitHub is not your friend for git issues. I woul dhope this site would support true FOSS

That is a little less than typical for me. I sometimes check out code to read it or to decide if I should compile and run it.

I too think package managers are amazing...

reads new git security threat

"brew upgrade"

done!

As the article states, it's a feature of git-gui, not the git CLI.

The vulnerability is Windows-only, so maybe whatever Windows users do to install git always gives them git-gui. But at least for Linux, the distro might package it separately (mine does), so you won't even have it if you didn't install it.

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.)

I'm guessing a system security update will patch the git executable. No way would apple make you update Xcode just for this. (Well, maybe...)

PR is now merged

The patched version is in testing https://src.fedoraproject.org/rpms/git

One way to find out!

Normally these posts would by called advisories (or more specifically security advisories)

Some vendors use the term Security Bulletins