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, brew install got me up to date.
> [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.
What is git doing with the system’s spell checker? This is the first time I’ve read about git using a spell checker. I know that various gui clients do spell checking, but I’m not aware of git itself doing anything related to this.
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.
Regarding first vulnerability with gIt format, how can malicious party exploit it? Someone needs to convince you to run git log format with some unusual format specifier, right? And then they need to access some specific memory location this way so they still need to store something malicious elsewhere. Sounds like it would be really extremely hard for anyone to exploit this.
Overall fixing this it looks like routine house keeping and nothing major.
> 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.
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.)
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.
> 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.
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):
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
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.
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).
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
I guess GitHub and similar providers could scan incoming commits for these in order to shield users who do not upgrade. We all know there will still be millions of those for years to come.
codazoda|3 years ago
`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, brew install got me up to date.
jasonmarks_|3 years ago
reads new git security threat
"brew upgrade"
done!
based2|3 years ago
sshine|3 years ago
To install the latest git on Ubuntu:
[Former post included instructions on how to install git from https://launchpad.net/~git-core/+archive/ubuntu/ppa]rlpb|3 years ago
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.
b112|3 years ago
adrianmonk|3 years ago
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.
bouke|3 years ago
Arnavion|3 years ago
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.
ffjffsfr|3 years ago
Overall fixing this it looks like routine house keeping and nothing major.
joernchen|3 years ago
> 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.
gwbas1c|3 years ago
japanman425|3 years ago
tomesco|3 years ago
I have upgraded my brew install, but am unsure of what to do with the vulnerable system install.
saurik|3 years ago
bobbylarrybobby|3 years ago
unknown|3 years ago
[deleted]
tinus_hn|3 years ago
nequo|3 years ago
bbojan|3 years ago
shepmaster|3 years ago
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.
xxpor|3 years ago
Because that's what processors do? (leaving aside backwards compatibility issues)
sshine|3 years ago
https://doc.rust-lang.org/std/?search=overflowing
It's generally less ergonomic, e.g.
jcranmer|3 years ago
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.
Kon-Peki|3 years ago
This crashes in Swift
This does not crash [1] https://docs.swift.org/swift-book/LanguageGuide/AdvancedOper...kgeist|3 years ago
weinzierl|3 years ago
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.
dcsommer|3 years ago
topspin|3 years ago
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.
nine_k|3 years ago
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).
hot_gril|3 years ago
remirk|3 years ago
mdaniel|3 years ago
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...
unknown|3 years ago
[deleted]
heywhatupboys|3 years ago
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
xnormal|3 years ago
unknown|3 years ago
[deleted]
elric|3 years ago
wtfishackernews|3 years ago
williamsmj|3 years ago
lucb1e|3 years ago
divbzero|3 years ago
https://github.com/Homebrew/homebrew-core/pull/120818
david_allison|3 years ago
unknown|3 years ago
[deleted]
AdmiralAsshat|3 years ago
fabianhjr|3 years ago
Some vendors use the term Security Bulletins
unknown|3 years ago
[deleted]
rust_is_dead|3 years ago
[deleted]