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

41–50 of 139 posts

Re: Git security vulnerabilities announced

#41

Post by IncRnd »

dcsommer wrote: post #23
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.

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.

> Integer overflow isn't a security issue unless your program's memory safety depends on the correctness of the integer operation.

That's simply not true and has wide-reaching horrible effects that can occur. The wrong number of tickets can be purchased from a website, charging for less than were purchased. The DNR order can be put in place instead of SAVE LIFE. There are countless security issues that can occur.

Saying that integer overflow is only an issue for memory safety is really bad and incorrect advice.

Re: Git security vulnerabilities announced

#42

Post by sshine »

kgeist wrote: post #17
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 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 parano…

My contribution to two open-source projects in recent years has involved a transition to the use of safe arithmetic, too.

I think it makes a lot of sense to think about. Ultimately, it matters more in some applications than in others.

Re: Git security vulnerabilities announced

#43

Post by heywhatupboys »

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

Re: Git security vulnerabilities announced

#44

Post by soiler »

sshine wrote: post #42
kgeist wrote: post #17

Earlier quoted context omitted.

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

My contribution to two open-source projects in recent years has involved a transition to the use of safe arithmetic, too. I think it makes a lot of sense to think about. Ultimately, it matters more in some applications than in others.

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

Re: Git security vulnerabilities announced

#46

Post by rlpb »

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 ]

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

Re: Git security vulnerabilities announced

#47

Post by unshavedyak »

IncRnd wrote: post #41
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.

> Integer overflow isn't a security issue unless your program's memory safety depends on the correctness of the integer operation. That's simply not true and has wide-reaching horrible effects that can occur. The wrong number of tickets can be purchased from a website, charging for less than were purchased. The DNR order can be put in place instead of SAVE LIFE. There are countless security issues that can occur. Say…

That's most logic issues though, is it not? I agree with you though, i wish Rust more commonly pushed "safer" (not in the UB way) code, like `Vec::get` and `u32::overflow_add` and etc.

Luckily lints help to easily ban the arithmetic/etc ops from projects. Nevertheless i feel it should be a bit closer to Rust's home.

Re: Git security vulnerabilities announced

#48

Post by mdaniel »

Arnavion wrote: post #20
bouke wrote: post #13

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.

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

Re: Git security vulnerabilities announced

#49

Post by p4l4g4 »

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 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 denial of service.

Can imagine that implementing bounds checking can be costly, when done in software. Wonder if there are any hardware improvements that could reduce risk in this area.

Re: Git security vulnerabilities announced

#50

Post by dcsommer »

IncRnd wrote: post #41
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.

> Integer overflow isn't a security issue unless your program's memory safety depends on the correctness of the integer operation. That's simply not true and has wide-reaching horrible effects that can occur. The wrong number of tickets can be purchased from a website, charging for less than were purchased. The DNR order can be put in place instead of SAVE LIFE. There are countless security issues that can occur. Say…

Do you have data on the relative frequency and severity of non-memory safety integer overflow security issues?
Post reply on HN