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

71–80 of 139 posts

Re: Git security vulnerabilities announced

#71

Post by comex »

CorrectHorseBat wrote: post #58
shepmaster wrote: post #5

Earlier quoted context omitted.

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

> 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 opting out of a ton of optimizations. With care it may be possible to recover most of those optimizations, but it would require major improvements to LLVM.

Re: Git security vulnerabilities announced

#72

Post by astrange »

kibwen wrote: post #25
shepmaster wrote: post #5

Earlier quoted context omitted.

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

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 just as bad as any other kind of bug. Security bugs/memory corruption don't always deserve the extra special treatment they get, nor are they the only kind of remotely exploitable issue.

Re: Git security vulnerabilities announced

#73

Post by joernchen »

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…

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.

Re: Git security vulnerabilities announced

#74

Post by CorrectHorseBat »

dahfizz wrote: post #68
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?

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.

Re: Git security vulnerabilities announced

#75

Post by heywhatupboys »

OJFord wrote: post #54
heywhatupboys wrote: post #43

Earlier quoted context omitted.

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

No it shouldn't, an hour in this submission might have barely 7 points, not 177, and probably a comment or two bemoaning the readability and pointing out the clearer write-up(s) available for people not already keeping up with the mailing list. If you don't believe me, have a look, this was probably submitted too, and is languishing somewhere off the front page while this one is at the top, by virtue of people voting…

lack of accessibility/discoverability and meager focus on looks has been a staple of FOSS for decades, but HN should be a site that helped with this, not one that supported proprietary uses of FOSS software to the benefit of an anti-competitive behemoth such as MS

Re: Git security vulnerabilities announced

#77

Post by hansvm »

xxpor wrote: post #36
hyperhopper wrote: post #29

Earlier quoted context omitted.

Our processors also require manually manipulating registers. The whole point of higher level programming languages is to abstract away the fiddly bits of dealing with processors that we don't want to have to deal with. This is one of those cases.

In cases where you're willing to take the perf hit, you can just use languages like Python which abstract over integer size entirely.

Which used to, but at least for parsing ints they've snuck in the perf hit as a "security vulnerability."

Re: Git security vulnerabilities announced

#78

Post by Kon-Peki »

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

Re: Git security vulnerabilities announced

#79

Post by viraptor »

topspin wrote: post #67
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 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.

Re: Git security vulnerabilities announced

#80

Post by naniwaduni »

HideousKojima wrote: post #38
hyperhopper wrote: post #30

Earlier quoted context omitted.

You don't know the business logic of every program. You can't say that a rust program won't have a security issue due to this. `UserAccessLevel > Threshold` Like there could be a million ways an integer becoming small could mess up something. Also there are business logic issues as well

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.
Post reply on HN