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

81–90 of 139 posts

Re: Git security vulnerabilities announced

#81

Post by travisgriggs »

shepmaster wrote: post #5
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.

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

Fascinating. Haven't had a chance to do Rust yet, but I think I would change this so that they were consistent. I do embedded, and that kind of "behaves differently in different places" is the worst kind of bug to figure out.

Re: Git security vulnerabilities announced

#82

Post by HideousKojima »

naniwaduni wrote: post #80
HideousKojima wrote: post #38

Earlier quoted context omitted.

Sure, but a logic error is a fundamentally different class of error compared to a memory error. The potential harm of a logic error is limited in scope to what the program was written to be able to do. A memory error can lead to arbitrary code execution.

Logic errors can still be security issues, even if they don't violate memory safety.

Absolutely, and I didn't suggest otherwise. But a logic error generally won't lead to your entire system getting pwned unless the program that has the logic error is one for something like user administration or managing a database etc.

Re: Git security vulnerabilities announced

#83

Post by prbs23 »

CorrectHorseBat wrote: post #74
dahfizz wrote: post #68

Earlier quoted context omitted.

Integer arithmetic is a significant part of ~every program. A single branch that checks the overflow flag is not expensive. But branching on that flag every time you do integer math is death by a billion paper cuts.

Your could use interrupts, no? Basically free when not triggered and when triggered you probably don't care about performance anymore.

Most architectures do not provide an interrupt that is generated by an integer overflow. Since this would be a significant architectural change in the hardware, it can't be simply added in.

Additionally, if you are running inside an operating system, handling an interrupt usually incurs a trip through the kernel, which would add extra overhead every time an overflow did happen. Since there's a lot of software which depends on integers overflowing, this overhead on each overflow could significantly impact legacy software.

Re: Git security vulnerabilities announced

#84

Post by gwillen »

CorrectHorseBat wrote: post #74
dahfizz wrote: post #68

Earlier quoted context omitted.

Integer arithmetic is a significant part of ~every program. A single branch that checks the overflow flag is not expensive. But branching on that flag every time you do integer math is death by a billion paper cuts.

Your could use interrupts, no? Basically free when not triggered and when triggered you probably don't care about performance anymore.

x86 at one time had a single-byte instruction that would trap if the overflow bit was set, INTO. It doesn't exist in 64-bit mode, I believe, and it was never widely used as far as I know. The performance implications of adding even a single additional instruction to every integer operation were probably still prohibitive? (And there's a history in x86 of specialized clever instructions and mechanisms going unused, due to being slower than doing the same thing some other way.)

Re: Git security vulnerabilities announced

#85

Post by eklitzke »

shepmaster wrote: post #5
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.

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

Just in case people don't know, you can get the same behavior with C or C++ by invoking GCC or Clang with -ftrapv. I don't know about Rust, but for C and C++ -ftrapv will only fault on signed integer overflow, as signed integer overflow is UB in C/C++ but unsigned integer overflow is well defined (it's guaranteed to wrap around to zero on all platforms). So even if you're trapping on integer overflow, there are still plenty of weird things that can happen if you unintentionally overflow an unsigned integer.

Re: Git security vulnerabilities announced

#86

Post by astrange »

xxpor wrote: post #70
FatActor wrote: post #56

Earlier quoted context omitted.

Saturated arithmetic instructions do not do this.

And on the platforms where the ADD instruction uses saturated arithmetic I bet assert(UINT32_MAX + 1 == UINT32_MAX) in C passes.

Unsigned integers in C are defined to wrap on overflow, so they shouldn't be affected by what the underlying processor wants to do. And just because signed overflows are undefined doesn't mean you get what the processor provides either.

So basically, don't forget to test with UBSan.

(I don't like -fno-strict-overflow as a solution, because defining incorrect behavior isn't much better than undefined behavior.)

Re: Git security vulnerabilities announced

#87

Post by codazoda »

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.

Re: Git security vulnerabilities announced

#88

Post by superjan »

comex wrote: post #71
CorrectHorseBat wrote: post #58

Earlier quoted context omitted.

> I heard we are still waiting for the cost of performing those checks to be "reasonable" before thinking about making such a change. What I don't understand is, checking for integer overflow is extremely cheap in hardware, so why is there any cost for performing those checks? What am I missing?

Part of it is that most CPU architectures don’t make overflow checking as cheap as it could be (there’s no option to trap on overflow, so you need a branch after every arithmetic operation, which has some cost). Another part is the compiler: a lot of compiler optimizations assume that arithmetic is a pure operation that can be added and removed and reordered as needed. So right now, adding overflow checks means optin…

This is a great point. But how about if the language would allow the programmer to specify what range of values is expected for function input/output?

Then a compiler could try to reason about the computation and decide that overflow does not happen if all values are within bounds, and just add checks at the function boundaries.

Re: Git security vulnerabilities announced

#89

Post by gwbas1c »

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.

Re: Git security vulnerabilities announced

#90

Post by LegionMammal978 »

Kon-Peki wrote: post #78
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.

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

As others have mentioned, the default overflow behavior in Rust can be configured to panic. To explicitly wrap around on overflow in every configuration, you can use the newtype wrapper Wrapping, or use the wrapping_add(), wrapping_mul(), etc. methods on the basic integer types. There are also variations such as saturating_op(), checked_op(), and overflowing_op() to detect the overflow and handle it appropriately.
Post reply on HN