Git security vulnerabilities announced • Hacker News Board

Re: Git security vulnerabilities announced

#131

Post by claranathan217 » Wed, Jan 18, 2023, 8:27 AM UTC

lucb1e wrote: post #110

williamsmj wrote: post #108

I wonder if there's anyone left at Twitter to backport security fixes to the custom fork of git they use to support their monorepo.

One way to find out!

[flagged]

Re: Git security vulnerabilities announced

#132

Post by elric » Wed, Jan 18, 2023, 8:55 AM UTC

Seems like there are no updates available for Fedora just yet?

Re: Git security vulnerabilities announced

#133

Post by wtfishackernews » Wed, Jan 18, 2023, 8:58 AM UTC

elric wrote: post #132

Seems like there are no updates available for Fedora just yet?

The patched version is in testing https://src.fedoraproject.org/rpms/git

Re: Git security vulnerabilities announced

#134

Post by tomxor » Wed, Jan 18, 2023, 6:01 PM UTC

foresto wrote: post #118

tomxor wrote: post #100

Earlier quoted context omitted.

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?

Looks like it's tracked in Debian, but not addressed yet. https://security-tracker.debian.org/tracker/CVE-2022-23521 https://security-tracker.debian.org/tracker/CVE-2022-41903 https://www.debian.org/security/2023/ https://tracker.debian.org/pkg/git

Thank you!

Re: Git security vulnerabilities announced

#135

Post by saagarjha » Thu, Jan 19, 2023, 9:28 AM UTC

superjan wrote: post #88

comex wrote: post #71

Earlier quoted context omitted.

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.

This would require more checks, not fewer?

Re: Git security vulnerabilities announced

#136

Post by xxpor » Thu, Jan 19, 2023, 5:03 PM UTC

astrange wrote: post #86

xxpor wrote: post #70

Earlier quoted context omitted.

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

TIL modulo wrapping for unsigned ints is actually in the standard, I could have sworn it was implementation defined (as opposed to signed wrapping, which is undefined).

Re: Git security vulnerabilities announced

#137

Post by yencabulator » Thu, Jan 19, 2023, 9:39 PM UTC

woodruffw wrote: post #121

joe_guy wrote: post #119

Earlier quoted context omitted.

Running brew upgrade uses git, so it has to run the insecure git to upgrade.

Wait until you hear about how your OpenSSL patches get delivered!

Via signed Git tags?

  object 19cc035b6c6f2283573d29c7ea7f7d675cf750ce
  type commit
  tag openssl-3.0.7
  tagger Tomas Mraz  1667335515 +0100

  OpenSSL 3.0.7 release tag
  -----BEGIN PGP SIGNATURE-----

  iQJGBAABCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmNhhWASHHRvbWFzQG9w
  ZW5zc2wub3JnAAoJEFJ0ZqIcp55tZRkQAJKQ35fUFQ3Wfuj4vbNQNX0Iv/c11q9o
  7Li8A8ananoYhnW9tpVTfpBCHAbE/fvwY3TMCE6IzBsRcjjef1CAqtEEDYI39aEt
  Nr00hUTVQeeH95viYMhmelq6axjkX8dGjfZBufZPJzrKrrj/eZLfmL3A1nZ9yYeF
  MCTxzpcOtaanJQ35h1Ayx3Hj1mcfTixGZR1drlJa5pDoF3y40ysxt/3ZYRD0Z/hO
  NbQ5QK/GPjnBheJaha6X7BoGgMRzXCfVSqtP/hE2Szzdq3nkZbWuDYw8EQ+Nr8Ni
  Q0BIIZLQbTYf4lmTXMbZdgUFq9/vSFNuz2IudDGiHrVfV1HZrZigHly61gqaXhjF
  Uir2LjMEgMr7D4O0udM6RnR7A1Wn3++sc8m3bGHYj+j+oSHSiKpZ0yxKbGY0TITL
  1/vJMBZe46rW2qQi8WI4fkRnyRVc+L19AHqHYeA9XHMWKFgRKgHlf+yf2ysPKsD6
  lGYCFwLJrlec/Sq4mbwe59JwtQbf4LHUQ4k+M1Cr5q04WegMH/nFjOanv8Ehs1Se
  WqJZD/1O+p8Go71g7c8kJ9QYiHkkr/xgs8BF7WMlNw7df5za6V1Ns/VCMSfQ9HF8
  SlODL7NBffQr0A9rGD/AueN2pATzv1p90/Cz5VCIWRfCHMN6EmurdGcSJkSXRbjY
  SDAGDysitYmo
  =/eQF
  -----END PGP SIGNATURE-----

Re: Git security vulnerabilities announced

#138

Post by woodruffw » Thu, Jan 19, 2023, 10:28 PM UTC

yencabulator wrote: post #137

woodruffw wrote: post #121

Earlier quoted context omitted.

Wait until you hear about how your OpenSSL patches get delivered!

Via signed Git tags? object 19cc035b6c6f2283573d29c7ea7f7d675cf750ce type commit tag openssl-3.0.7 tagger Tomas Mraz 1667335515 +0100 OpenSSL 3.0.7 release tag -----BEGIN PGP SIGNATURE----- iQJGBAABCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmNhhWASHHRvbWFzQG9w ZW5zc2wub3JnAAoJEFJ0ZqIcp55tZRkQAJKQ35fUFQ3Wfuj4vbNQNX0Iv/c11q9o 7Li8A8ananoYhnW9tpVTfpBCHAbE/fvwY3TMCE6IzBsRcjjef1CAqtEEDYI39aEt Nr00hUTVQeeH95viYMhmelq6axjkX8dGjfZ…

And how, pray tell, are you downloading those signatures? Or the public keys corresponding to them, for that matter, if you don't have them locally already (and, if you do, why do you trust them given that your transport layer has been compromised?)

Besides: if you actually verify `git` signatures, you can count yourself in a club of less than a dozen people who bother. That isn't to say that you're wrong to, just that an optional signature is, to a first approximation, as useful as not signing at all.

Re: Git security vulnerabilities announced

#139

Post by yencabulator » Fri, Jan 20, 2023, 2:32 PM UTC

woodruffw wrote: post #138

yencabulator wrote: post #137

Earlier quoted context omitted.

Via signed Git tags? object 19cc035b6c6f2283573d29c7ea7f7d675cf750ce type commit tag openssl-3.0.7 tagger Tomas Mraz 1667335515 +0100 OpenSSL 3.0.7 release tag -----BEGIN PGP SIGNATURE----- iQJGBAABCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmNhhWASHHRvbWFzQG9w ZW5zc2wub3JnAAoJEFJ0ZqIcp55tZRkQAJKQ35fUFQ3Wfuj4vbNQNX0Iv/c11q9o 7Li8A8ananoYhnW9tpVTfpBCHAbE/fvwY3TMCE6IzBsRcjjef1CAqtEEDYI39aEt Nr00hUTVQeeH95viYMhmelq6axjkX8dGjfZ…

And how, pray tell, are you downloading those signatures? Or the public keys corresponding to them, for that matter, if you don't have them locally already (and, if you do, why do you trust them given that your transport layer has been compromised?) Besides: if you actually verify `git` signatures, you can count yourself in a club of less than a dozen people who bother. That isn't to say that you're wrong to, just th…

The public keys for those signatures have already been downloaded by any vendor who knows what they're doing; a new TLS forgery vulnerability won't really hurt there.

Or, let's put it this way: If you don't bother with the signatures, a TLS forgery likely isn't the easiest way to feed you a fake openssl release, hijacking an account or hacking Github et al are.

Also, Github itself verifies Git signatures, and the maintainers seem to have Github's "vigilant mode" on.