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

91–100 of 139 posts

Re: Git security vulnerabilities announced

#91

Post by wongarsu »

p4l4g4 wrote: post #49
kibwen wrote: post #25

Earlier quoted context omitted.

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 dangerous too though. E.g. Bumping a user ID, to get a "fresh" one or calculate port to open based on offset. When not bounded to a known range, this kind of logic can easily pose a serious security risk. Most of the time, it will probably just work, but under extreme conditions, it will fail. If your language at least catch the overflow and crash instead of wrapping around, you "only" have a denia…

If you identify an area as risky, it's trivial in Rust to do a checked_add or saturating_add. The challenge is obviously identifying this, but having easy library functions anectotally leads to people looking for it in code reviews.

Re: Git security vulnerabilities announced

#92

Post by _8dej »

shiftingleft wrote: post #26
dcsommer wrote: post #23

Earlier quoted context omitted.

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.

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?

Re: Git security vulnerabilities announced

#93

Post by weinzierl »

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.

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.

Re: Git security vulnerabilities announced

#94

Post by Kon-Peki »

LegionMammal978 wrote: post #90
Kon-Peki wrote: post #78

Earlier quoted context omitted.

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

Sure, I was suggesting that what the OP is asking for is not what Rust does, but what Swift does. This is not a configuration thing, if you don't want a runtime exception on overflow, you must use a different arithmetic operator.

Swift's behavior comes at a cost - it is not exactly the fastest language out there ;) Another no-overflow oddity is that Swift doesn't have a rand() equivalent. You can't get fast psuedorandom numbers in Swift unless you are on the Mac, in which case you can import GameplayKit and get gaming-appropriate pseudorandom numbers.

EDIT - to be clear, I am not suggesting that anyone change their own chosen programming language. But if you'd like, install Swift on your dev machine and make a Swift implementation of the critical section of your Rust code. Debug, optimize, tweak, etc. And you'll get a pretty good idea of what kind of performance you have to give up to do what many people are asking :)

Re: Git security vulnerabilities announced

#95

Post by zerocrates »

mdaniel wrote: post #48
Arnavion wrote: post #20

Earlier quoted context omitted.

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.

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.

Re: Git security vulnerabilities announced

#97

Post by nine_k »

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

Re: Git security vulnerabilities announced

#99

Post by kibwen »

travisgriggs wrote: post #81
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…

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.

> behaves differently in different places

It doesn't behave differently in different places, it differs based on build profile. You test in debug mode, which is where overflows will panic, which makes them quite obvious. If you want to pay the price of overflow checks everywhere in release mode, then you can turn them on there as well (it's not that much of a performance penalty, but that might not be true on embedded...). It's effectively just a compiler flag.

Re: Git security vulnerabilities announced

#100

Post by tomxor »

adrianmonk wrote: post #65
sshine wrote: post #7

[Edit: According to @rlpb's comment, git 2.39.1 is already available on Ubuntu] To install the latest git on Ubuntu: sudo apt upgrade git [Former post included instructions on how to install git from https://launchpad.net/~git-core/+archive/ubuntu/ppa ]

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

I'm not sure why they aren't bumping the patch number, maybe they decided against applying the other parts of the patch for least change - but at least the CVEs are mentioned in all of the Ubuntu changelogs.

I can't find anything in the Debian changelogs referring to the CVEs. Yet the Ubuntu changelog refers to it as a debian patch...

Anyone know anything about Debian?

Post reply on HN