Discussion:
Sébastien Luttringer and Tobias Powalowski
(too old to reply)
User via arch-general
2017-07-02 20:12:28 UTC
Permalink
Raw Message
Sébastien Luttringer, https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/btrfs-progs&id=959539e1f7df15986f336bb03225ea796a44ca3e , https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/sha256sums.asc, https://lists.archlinux.org/pipermail/arch-general/2016-December/042700.html .
Tobias Powalowski, https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/hdparm&id=2bd43d6fec063156c40dfc0d5ba115155b09cfc1 , i waited and no one said anything all this time. you do
Eli Schwartz via arch-general
2017-07-02 20:18:23 UTC
Permalink
Raw Message
Sébastien Luttringer, https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/btrfs-progs&id=959539e1f7df15986f336bb03225ea796a44ca3e , https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/sha256sums.asc, https://lists.archlinux.org/pipermail/arch-general/2016-December/042700.html .
Tobias Powalowski, https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/hdparm&id=2bd43d6fec063156c40dfc0d5ba115155b09cfc1 , i waited and no one said anything all this time. you do not help each other.
So basically, you are confirming you are fnodeuser?

I guess you thought this was a good way to get around being blacklisted
from the mailing list due to continuous rudeness and spammy behaviour.
--
Eli Schwartz
G. Schlisio
2017-07-02 20:21:11 UTC
Permalink
Raw Message
Post by Eli Schwartz via arch-general
Post by User via arch-general
Sébastien Luttringer, https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/btrfs-progs&id=959539e1f7df15986f336bb03225ea796a44ca3e , https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/sha256sums.asc, https://lists.archlinux.org/pipermail/arch-general/2016-December/042700.html .
Tobias Powalowski, https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/hdparm&id=2bd43d6fec063156c40dfc0d5ba115155b09cfc1 , i waited and no one said anything all this time. you do not help each other.
So basically, you are confirming you are fnodeuser?
I guess you thought this was a good way to get around being blacklisted
from the mailing list due to continuous rudeness and spammy behaviour.
Oh, please dont feed the troll… its exactly what he's aiming for.
Eli Schwartz via arch-general
2017-07-02 20:23:50 UTC
Permalink
Raw Message
Oh, please dont feed the troll
 its exactly what he's aiming for.
I thought it was important that everyone know exactly who they are
dealing with (because he has a lot of history here and has now
progressed to hiding his name/handle). Otherwise I wouldn't have replied
at all.

So yeah, the fact that this is fnodeuser again is the only observation I
have to make this time. :)
--
Eli Schwartz
Ralf Mardorf
2017-07-02 20:30:14 UTC
Permalink
Raw Message
Post by Eli Schwartz via arch-general
So basically, you are confirming you are fnodeuser?
IMO it's better not to reply to her/him and instead to inform
arch-general-***@archlinux.org , just in case it wasn't already
noticed.

https://lists.archlinux.org/pipermail/arch-general/2017-July/043853.html
https://lists.archlinux.org/pipermail/arch-general/2017-July/043854.html
NicoHood
2017-07-02 20:39:37 UTC
Permalink
Raw Message
Post by Eli Schwartz via arch-general
Sébastien Luttringer, https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/btrfs-progs&id=959539e1f7df15986f336bb03225ea796a44ca3e , https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/sha256sums.asc, https://lists.archlinux.org/pipermail/arch-general/2016-December/042700.html .
Tobias Powalowski, https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/hdparm&id=2bd43d6fec063156c40dfc0d5ba115155b09cfc1 , i waited and no one said anything all this time. you do not help each other.
So basically, you are confirming you are fnodeuser?
I guess you thought this was a good way to get around being blacklisted
from the mailing list due to continuous rudeness and spammy behaviour.
I've checked the links and while those suggestions are a bit harsh, they
are still valid:

* btrfs-progs can use stronger hashes. This always makes sense and can
be changed within seconds. Especially because upstream hashes are
available for comparison beside the Signature.
* The suggestion to add sha2 hashes for the .iso download is valid.
There is no good reason why to not also add another (more secure)
algorithm, no matter if the current solution might be okay today, but
maybe not in the future.
* The last link shows a real issue of the PKGBUILD. The sha512 values
are wrong and on top of that the variable name is misspelled (double
ss). This should be fixed and only contains sha512sums or both

No matter who he is, he is right. Also with his previous email, we
should build systemd with https sources. If we ever have malicious
software in our Distribution we will get lots of trouble. And we dont
want this to happen just because we did not apply such an obvious fix.

So why are we so resistant against those suggestions? Those are good and
valid, no matter who this guy is and how he interacts with people. From
the technical point of view he is right. And we all should care for our
users, because we are responsible for them.

~Nico
Martin Kühne via arch-general
2017-07-02 21:05:30 UTC
Permalink
Raw Message
Post by NicoHood
So why are we so resistant against those suggestions? Those are good and
valid, no matter who this guy is and how he interacts with people. From
the technical point of view he is right. And we all should care for our
users, because we are responsible for them.
https://lists.archlinux.org/pipermail/arch-general/2017-July/043860.html

You know I thought about the factuality part of the emails writing my
response too, and it turned out I couldn't criticise the content for
anything but harshness. This is going to an interesting place, and
we'll have to decide how we can deal with content like this in a way
that tells the source to go f themselves while paying actual attention
to valid criticism...

cheers!
mar77i
NicoHood
2017-07-02 21:30:15 UTC
Permalink
Raw Message
Post by Martin Kühne via arch-general
Post by NicoHood
So why are we so resistant against those suggestions? Those are good and
valid, no matter who this guy is and how he interacts with people. From
the technical point of view he is right. And we all should care for our
users, because we are responsible for them.
https://lists.archlinux.org/pipermail/arch-general/2017-July/043860.html
You know I thought about the factuality part of the emails writing my
response too, and it turned out I couldn't criticise the content for
anything but harshness. This is going to an interesting place, and
we'll have to decide how we can deal with content like this in a way
that tells the source to go f themselves while paying actual attention
to valid criticism...
cheers!
mar77i
You are right. I think this has all its past and we should just go on
and fix our Distribution. He reminds me a bit of Torvalds, from what
I've heard. It has its pro and its cons.

We should use those suggestions, as they are really helpful. Actually it
is really good to have someone carefully reviewing and watching our
PKGBUILDs.

As another idea we maybe could consider to write more precise PKGBUILD
standards for security measures, which e.g. define that HTTPS must be
used, whenever available etc. This way people like him can be of a huge
help and we can improve our PKGBUILD security continuously. This would
help everyone. How about that?

~Nico
Martin Kühne via arch-general
2017-07-02 21:58:10 UTC
Permalink
Raw Message
I stand corrected which leaves only part of my last sentence. Thanks
for the detailed heads-up, everyone, especially Eli.
Post by Martin Kühne via arch-general
we'll have to decide how we can deal with content like this in a way
that tells the source to go f themselves [content is hereby retracted]...
have a good night and new week, everyone.
except User: go f yourself.

cheers!
mar77i
Eli Schwartz via arch-general
2017-07-02 21:38:11 UTC
Permalink
Raw Message
... so, apparently, people are determined to actually fall for this
clown. I was initially going to send this off-list, but I'd just like to
shut down these claims fast before people start falling for it. We
already had two people fall for it, people whose opinions I am not
generally inclined to disrespect.

Let's make this clear: None of these claims are true! At all! Not even
one of them!
Post by NicoHood
I've checked the links and while those suggestions are a bit harsh, they
You have grabbed the troll bait! Please don't do that. Also, you're wrong.
Post by NicoHood
* btrfs-progs can use stronger hashes. This always makes sense and can
be changed within seconds. Especially because upstream hashes are
available for comparison beside the Signature.
Calling out specific package *maintainers* for a public shaming is
always unacceptable, and picking on specific packages for the sake of
something that only makes sense in the context of a *distro-wide* policy
makes NO SENSE. Lots of things can use stronger hashes, in theory. We
have ridden this hobby-horse all over arch-general, repeatedly, as you
should know due to having contributed no small part of that conversation
yourself. I am sick and tired of hearing you and others reignite that
debate every time someone mentions the word "checksums", you aren't
contributing any useful discussion about policy anymore.

Posting about these packages and attempting to shame their maintainers
on the mailing list is unacceptable, in the way posting to the mailing
list about the chemical composition of peanut butter is unacceptable.
Post by NicoHood
* The suggestion to add sha2 hashes for the .iso download is valid.
There is no good reason why to not also add another (more secure)
algorithm, no matter if the current solution might be okay today, but
maybe not in the future.
Stop being ludicrous. No one believes that you need two different
hashes, sha256 is completely acceptable, end of story, and quite
frankly, we use GPG signatures there so CRC checksums are all we need
(and sha256 is way overkill but we have them anyway, so congrats).

Are you genuinely trying to tell me you think there is something you
haven't already said last time, which you think is useful to say
regarding a potential *distro policy* ?
Post by NicoHood
* The last link shows a real issue of the PKGBUILD. The sha512 values
are wrong and on top of that the variable name is misspelled (double
ss). This should be fixed and only contains sha512sums or both
That PKGBUILD is ugly in the extreme due to containing junk variables
that do not exist in any sense of pacman's source build systems, but it
also only contains md5sums. Valid md5sums. Stop spreading FUD.

This package therefore falls under the category of "attempted public
shaming of packages using md5sums", and also "attempted public shaming
of a specific *person* for making a stupid typo". This is not a valid
point, this is exclusively rudeness with the explicit attempt to be rude.

And you've fallen for it, hook, line, and sinker.
Post by NicoHood
No matter who he is, he is right. Also with his previous email, we
should build systemd with https sources. If we ever have malicious
software in our Distribution we will get lots of trouble. And we dont
want this to happen just because we did not apply such an obvious fix.
systemd is validated with GPG, it doesn't matter whether the download
transport is checked against the cacert system. GPG already ensures that
this package cannot sneakily use a source that isn't signed with the
validpgpkeys.
Post by NicoHood
So why are we so resistant against those suggestions? Those are good and
valid, no matter who this guy is and how he interacts with people. From
the technical point of view he is right. And we all should care for our
users, because we are responsible for them.
Because he has been banned from the forums, from IRC, from the
bugtracker, and from the mailing list due to extreme rudeness that makes
him intolerable to talk to, and also because he is wrong or a liar, more
often than he is right.

And because you just fell for him, as many well-meaning people who
aren't familiar with him do.
--
Eli Schwartz
NicoHood
2017-07-02 21:55:35 UTC
Permalink
Raw Message
Post by Eli Schwartz via arch-general
Let's make this clear: None of these claims are true! At all! Not even
one of them!
You just say its not true, but that is wrong. I've wrote a statement for
every link he pointed out in which way it is valid or not.
Post by Eli Schwartz via arch-general
You have grabbed the troll bait! Please don't do that. Also, you're wrong.
You are also a troll, as you just block with "STOP TROLLING". That is
even more annoying to me.
Post by Eli Schwartz via arch-general
Posting about these packages and attempting to shame their maintainers
on the mailing list is unacceptable, in the way posting to the mailing
list about the chemical composition of peanut butter is unacceptable.
Yes, we should not shame specific people, I've learned this myself. He
picked a few packages from few maintainers. We DO have SERIOUS security
issues in PGBUILDs that we CAN fix, but just dont, because of no obvious
reason.
Post by Eli Schwartz via arch-general
systemd is validated with GPG, it doesn't matter whether the download
transport is checked against the cacert system. GPG already ensures that
this package cannot sneakily use a source that isn't signed with the
validpgpkeys.
Yes the GPG signature of the tag commit is checked. However you can
attack the git metadata and set a tag to a different commit. If this
commit is signed, but at an older stage which is vulnearable, we have an
issue. Just one example. So we should always also secure the transport
layer.
https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias

You are just complaining the loudest. Doesnt mean you are right, nor
better. If we just fix our PKGBUILDs, noone can troll.

How do you think can we improve the PKGBUILD security if we reject
suggestions like this? What would be your plan? Waiting for an attacker
to proof that we should have fixed our PKGBUILDs earlier?
Morten Linderud
2017-07-02 22:07:07 UTC
Permalink
Raw Message
Post by NicoHood
Yes the GPG signature of the tag commit is checked. However you can
attack the git metadata and set a tag to a different commit. If this
commit is signed, but at an older stage which is vulnearable, we have an
issue. Just one example. So we should always also secure the transport
layer.
https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias
The sign includes the hash. You would essentially have to trick Lennart into replacing the tag to a different commit,
and sign the tag. Creating a vulnerable but verified source for the PKGBUILD. At this point i think we have bigger
problems then whatever the PKGBUILD is doing...
--
Morten Linderud

PGP: 9C02FF419FECBE16
NicoHood
2017-07-02 22:16:53 UTC
Permalink
Raw Message
Post by Morten Linderud
Post by NicoHood
Yes the GPG signature of the tag commit is checked. However you can
attack the git metadata and set a tag to a different commit. If this
commit is signed, but at an older stage which is vulnearable, we have an
issue. Just one example. So we should always also secure the transport
layer.
https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias
The sign includes the hash. You would essentially have to trick Lennart into replacing the tag to a different commit,
and sign the tag. Creating a vulnerable but verified source for the PKGBUILD. At this point i think we have bigger
problems then whatever the PKGBUILD is doing...
Thats is exactly what I mean. If I understood right you can modify the
git metadata in a way that you can pull tag 1.2 but get 1.0. And tag 1.0
is gpg signed and all valid. This seems to work for me.

I've added sangy to this email, he is the author of this presentation
and should know best. sangy, can you please give us some more detailed
information if an attack could still compromise the systemd package with
a modified git source but still gpg signed commits?

~Nico
Morten Linderud
2017-07-02 22:21:01 UTC
Permalink
Raw Message
Post by NicoHood
Post by Morten Linderud
Post by NicoHood
Yes the GPG signature of the tag commit is checked. However you can
attack the git metadata and set a tag to a different commit. If this
commit is signed, but at an older stage which is vulnearable, we have an
issue. Just one example. So we should always also secure the transport
layer.
https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias
The sign includes the hash. You would essentially have to trick Lennart into replacing the tag to a different commit,
and sign the tag. Creating a vulnerable but verified source for the PKGBUILD. At this point i think we have bigger
problems then whatever the PKGBUILD is doing...
Thats is exactly what I mean. If I understood right you can modify the
git metadata in a way that you can pull tag 1.2 but get 1.0. And tag 1.0
is gpg signed and all valid. This seems to work for me.
But at this point you can't trust critical maintainers of important software. This isn't a threat model i think
PKGBUILDs (or Arch for that matter) really cares about. Am i wrong? Or are you implying MITM attacks can trick the
packager into packaging broken software?
--
Morten Linderud

PGP: 9C02FF419FECBE16
NicoHood
2017-07-02 22:25:22 UTC
Permalink
Raw Message
Post by Morten Linderud
Post by NicoHood
Post by Morten Linderud
Post by NicoHood
Yes the GPG signature of the tag commit is checked. However you can
attack the git metadata and set a tag to a different commit. If this
commit is signed, but at an older stage which is vulnearable, we have an
issue. Just one example. So we should always also secure the transport
layer.
https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias
The sign includes the hash. You would essentially have to trick Lennart into replacing the tag to a different commit,
and sign the tag. Creating a vulnerable but verified source for the PKGBUILD. At this point i think we have bigger
problems then whatever the PKGBUILD is doing...
Thats is exactly what I mean. If I understood right you can modify the
git metadata in a way that you can pull tag 1.2 but get 1.0. And tag 1.0
is gpg signed and all valid. This seems to work for me.
But at this point you can't trust critical maintainers of important software. This isn't a threat model i think
PKGBUILDs (or Arch for that matter) really cares about. Am i wrong? Or are you implying MITM attacks can trick the
packager into packaging broken software?
Sure it is all about MITM, as we are talking about using https over
http. I am not sure if I am right. But why are we even discussing if
https is available? It will just make things better.
Morten Linderud
2017-07-02 22:29:44 UTC
Permalink
Raw Message
Post by NicoHood
Post by Morten Linderud
Post by NicoHood
Post by Morten Linderud
Post by NicoHood
Yes the GPG signature of the tag commit is checked. However you can
attack the git metadata and set a tag to a different commit. If this
commit is signed, but at an older stage which is vulnearable, we have an
issue. Just one example. So we should always also secure the transport
layer.
https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias
The sign includes the hash. You would essentially have to trick Lennart into replacing the tag to a different commit,
and sign the tag. Creating a vulnerable but verified source for the PKGBUILD. At this point i think we have bigger
problems then whatever the PKGBUILD is doing...
Thats is exactly what I mean. If I understood right you can modify the
git metadata in a way that you can pull tag 1.2 but get 1.0. And tag 1.0
is gpg signed and all valid. This seems to work for me.
But at this point you can't trust critical maintainers of important software. This isn't a threat model i think
PKGBUILDs (or Arch for that matter) really cares about. Am i wrong? Or are you implying MITM attacks can trick the
packager into packaging broken software?
Sure it is all about MITM, as we are talking about using https over
http. I am not sure if I am right. But why are we even discussing if
https is available? It will just make things better.
But HTTPS doesnt matter here. We have a trusted signer inn the PKGBUILD, anyone can MITM for the good of their life.
Unless they can fake the signature (Hint; they cant), or trick Lennart into signing something he shouldnt (Hint; he
wont), we don't have a case here. It doesn't really matter if its HTTP or HTTPS.

You also didn't really reply about the threat model.
--
Morten Linderud

PGP: 9C02FF419FECBE16
Ismael Bouya
2017-07-02 23:01:35 UTC
Permalink
Raw Message
Post by Morten Linderud
But HTTPS doesnt matter here. We have a trusted signer inn the PKGBUILD, anyone can MITM for the good of their life.
Unless they can fake the signature (Hint; they cant), or trick Lennart into signing something he shouldnt (Hint; he
wont), we don't have a case here. It doesn't really matter if its HTTP or HTTPS.
You also didn't really reply about the threat model.
If I understand correctly what Nicohood meant,
what could happen is that version X of systemd (or anything else) has a
well known vulnerability, fixed in X+1. X+1 is packaged, so anyone
up to date thinks "good I'm safe now". But since a man in the middle can
force to download version X (signed by the systemd maintainer so
considered "secure"), he can force you to download that version when you
create the package and you'll think you have the safe version while
having the unsafe one.

If that happens to the packager in archlinux, then you poisoned all
archlinux users.

(but then, the md5sum will be wrong anyway?)
--
Ismael
Morten Linderud
2017-07-02 23:06:04 UTC
Permalink
Raw Message
Post by Ismael Bouya
Post by Morten Linderud
But HTTPS doesnt matter here. We have a trusted signer inn the PKGBUILD, anyone can MITM for the good of their life.
Unless they can fake the signature (Hint; they cant), or trick Lennart into signing something he shouldnt (Hint; he
wont), we don't have a case here. It doesn't really matter if its HTTP or HTTPS.
You also didn't really reply about the threat model.
If I understand correctly what Nicohood meant,
what could happen is that version X of systemd (or anything else) has a
well known vulnerability, fixed in X+1. X+1 is packaged, so anyone
up to date thinks "good I'm safe now". But since a man in the middle can
force to download version X (signed by the systemd maintainer so
considered "secure"), he can force you to download that version when you
create the package and you'll think you have the safe version while
having the unsafe one.
If that happens to the packager in archlinux, then you poisoned all
archlinux users.
(but then, the md5sum will be wrong anyway?)
--
Ismael
At this point we can't trust the trusted users to build and verify the correct packages, let alone maintaine a safe
infrastructure to build packages. This is a slippery slope, and i really fucking hope this isn't a serious issue any
devs or TUs are afraid of.
--
Morten Linderud

PGP: 9C02FF419FECBE16
Ismael Bouya
2017-07-02 23:20:58 UTC
Permalink
Raw Message
Post by Morten Linderud
At this point we can't trust the trusted users to build and verify the
correct packages, let alone maintaine a safe infrastructure to build
packages. This is a slippery slope, and i really fucking hope this
isn't a serious issue any devs or TUs are afraid of.
I didn’t imply that, but it’s easy to rely on the "gpg check" to skip
other checks.

I never faced the problem, but right out of my mind I don’t know how to
download a git project archive and check easily that I got the correct
tag.
--
Ismael
Eli Schwartz via arch-general
2017-07-02 23:22:23 UTC
Permalink
Raw Message
Post by Ismael Bouya
Post by Morten Linderud
But HTTPS doesnt matter here. We have a trusted signer inn the PKGBUILD, anyone can MITM for the good of their life.
Unless they can fake the signature (Hint; they cant), or trick Lennart into signing something he shouldnt (Hint; he
wont), we don't have a case here. It doesn't really matter if its HTTP or HTTPS.
You also didn't really reply about the threat model.
If I understand correctly what Nicohood meant,
what could happen is that version X of systemd (or anything else) has a
well known vulnerability, fixed in X+1. X+1 is packaged, so anyone
up to date thinks "good I'm safe now". But since a man in the middle can
force to download version X (signed by the systemd maintainer so
considered "secure"), he can force you to download that version when you
create the package and you'll think you have the safe version while
having the unsafe one.
Okay, this I am genuinely curious about.

In what circumstances can I have:
- the systemd repository cloned over the git:// protocol
- an annotated tag for systemd v233 signed by Lennart Poettering.
- an annotated tag for systemd v232 signed by Lennart Poettering.
- a man in the middle attack
- `git verify-tag --raw v233` reports a GOODSIG with a VALIDSIG
${fingerprint} that matches with Lennart's known GPG fingerprint as
recorded in validpgpkeys

And as a result, when I run the git command `git checkout
refs/tags/v233`, I am tricked into getting v232 instead which contains a
vulnerability. Also, I wouldn't be alerted by the verbose printing of
the systemd version which happens during the boot process, nor by
$systemd_binary --version

...

Because I don't think git works that way, but I am willing to be proven
wrong. Also I bet the git developers would be fascinated to hear the
details, you might even get some sort of bounty for successfully hacking
git like that.
--
Eli Schwartz
Ismael Bouya
2017-07-02 23:34:38 UTC
Permalink
Raw Message
Post by Eli Schwartz via arch-general
Okay, this I am genuinely curious about.
- the systemd repository cloned over the git:// protocol
- an annotated tag for systemd v233 signed by Lennart Poettering.
- an annotated tag for systemd v232 signed by Lennart Poettering.
- a man in the middle attack
- `git verify-tag --raw v233` reports a GOODSIG with a VALIDSIG
${fingerprint} that matches with Lennart's known GPG fingerprint as
recorded in validpgpkeys
And as a result, when I run the git command `git checkout
refs/tags/v233`, I am tricked into getting v232 instead which contains a
vulnerability.
Until there, it's exactly the topic of the presentation linked by
Nicohood
Post by Eli Schwartz via arch-general
Also, I wouldn't be alerted by the verbose printing of
the systemd version which happens during the boot process, nor by
$systemd_binary --version
Then you rely only on that last two things
--
Ismael
Eli Schwartz via arch-general
2017-07-03 02:14:00 UTC
Permalink
Raw Message
Post by Ismael Bouya
Post by Eli Schwartz via arch-general
Okay, this I am genuinely curious about.
- the systemd repository cloned over the git:// protocol
- an annotated tag for systemd v233 signed by Lennart Poettering.
- an annotated tag for systemd v232 signed by Lennart Poettering.
- a man in the middle attack
- `git verify-tag --raw v233` reports a GOODSIG with a VALIDSIG
${fingerprint} that matches with Lennart's known GPG fingerprint as
recorded in validpgpkeys
And as a result, when I run the git command `git checkout
refs/tags/v233`, I am tricked into getting v232 instead which contains a
vulnerability.
Until there, it's exactly the topic of the presentation linked by
Nicohood
So I was under the impression that git tags encode the tagname in the
actual blob, and I didn't see how that attack (rooted in the basic
nature of a branch as a lightweight, mutable, *pushable* pointer to a
commit) was supposed to work unless of course it was talking about a
lightweight tag (which is not really meant for public/permanent use)...

Having actually tested this out, I find myself quite bewildered.

Because, git *does* encode the tagname in the blob, like I thought.
And... you *can* simply copy .git/refs/tags/tagname to create a fake
tag, and then you see something quite bewildering:

```
[***@arch ~/git]$ git clone https://github.com/systemd/systemd
[...]
[***@arch ~/git]$ cd systemd
[***@arch ~/git/systemd]$ echo "$(git show-ref -s v233)" >
.git/refs/tags/v232
[***@arch ~/git/systemd]$ git tag -v v232
object d60c527009133a1ed3d69c14b8c837c790e78d10
type commit
tag v233
tagger Lennart Poettering <***@poettering.net> 1488405946 +0100

systemd 233
gpg: Signature made Wed 01 Mar 2017 05:05:46 PM EST
gpg: using RSA key B63B21879C3485B0
gpg: Good signature from "Lennart Poettering <***@poettering.net>"
[unknown]
gpg: aka "Lennart Poettering <***@poettering.de>"
[unknown]
gpg: aka "Lennart Poettering (Red Hat)
<***@redhat.com>" [unknown]
gpg: aka "Lennart Poettering (Sourceforge.net)
<***@users.sourceforge.net>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 63CD A1E5 D3FC 22B9 98D2 0DD6 327F 2695 1A01 5CC4
Subkey fingerprint: 16B1 C4EE C0BC 021A C777 F681 B63B 2187 9C34 85B0
```

I simply do not understand why git doesn't error when it sees that a tag
ref named v232 points to a tag blob named v233. The information is all
there, and it seems trivial to add a check.

Oh well, one more reason to use commit hashes rather than pkgver tags.
(The other reason is, because upstreams themselves are quite capable of
modifying tags and re-signing them without waiting for some attacker to
play with the ref pointers.)

Anyway, I learned something today.
--
Eli Schwartz
Giovanni Santini via arch-general
2017-07-03 20:43:41 UTC
Permalink
Raw Message
Post by Eli Schwartz via arch-general
So I was under the impression that git tags encode the tagname in the
actual blob, and I didn't see how that attack (rooted in the basic
nature of a branch as a lightweight, mutable, *pushable* pointer to a
commit) was supposed to work unless of course it was talking about a
lightweight tag (which is not really meant for public/permanent use)...
Having actually tested this out, I find myself quite bewildered.
Because, git *does* encode the tagname in the blob, like I thought.
And... you *can* simply copy .git/refs/tags/tagname to create a fake
```
[...]
.git/refs/tags/v232
object d60c527009133a1ed3d69c14b8c837c790e78d10
type commit
tag v233
systemd 233
gpg: Signature made Wed 01 Mar 2017 05:05:46 PM EST
gpg: using RSA key B63B21879C3485B0
[unknown]
[unknown]
gpg: aka "Lennart Poettering (Red Hat)
gpg: aka "Lennart Poettering (Sourceforge.net)
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 63CD A1E5 D3FC 22B9 98D2 0DD6 327F 2695 1A01 5CC4
Subkey fingerprint: 16B1 C4EE C0BC 021A C777 F681 B63B 2187 9C34 85B0
```
I simply do not understand why git doesn't error when it sees that a tag
ref named v232 points to a tag blob named v233. The information is all
there, and it seems trivial to add a check.
Oh well, one more reason to use commit hashes rather than pkgver tags.
(The other reason is, because upstreams themselves are quite capable of
modifying tags and re-signing them without waiting for some attacker to
play with the ref pointers.)
Anyway, I learned something today.
I think I can reply to this. Just skip if not interesed to last part.

"""Thanks""" to a lab of a class I had the previous semester, I can
describe you exactly how Git blobs are... There are:
- normal *blob*s: standard files compressed using Deflate, have only a
small special header at the top
- *tree*s: a specially encoded file, pointing to blobs or other
*tree*s... call them *blobbed directories*
- *commits*: another deflated file, keeping the commit message and a
reference to a *tree*.
To be 100% I made one just now to check and I can say that we have
- *tags*: a plain file referring to a commit object

You see the point: you just renamed a text file pointing others. Unless
you change the commit binary file (doing this won't pass the gpg check)
or fake the whole .git blobs, it will point to the v233 commit and all
the stuff below it.
If you are instead saying that Git should notice that the file in the
refs folder is named improperly, just `man git` and see what *git* is :P :D

tl;dr: Too much an hassle; destroying a Git repo is easy, faking it is not.

P.S. Thanks to that class, we made some Java classes to handle Git
blobs, check them if you want: https://gitlab.com/ItachiSan/lab01/
--
Giovanni Santini
My blog: http://giovannisantini.tk
My code: https://git{hub,lab}.com/ItachiSan
My GPG: 2FADEBF5
Damjan Georgievski via arch-general
2017-07-03 10:27:37 UTC
Permalink
Raw Message
On 3 July 2017 at 01:22, Eli Schwartz via arch-general
Post by Eli Schwartz via arch-general
Post by Ismael Bouya
Post by Morten Linderud
But HTTPS doesnt matter here. We have a trusted signer inn the PKGBUILD, anyone can MITM for the good of their life.
Unless they can fake the signature (Hint; they cant), or trick Lennart into signing something he shouldnt (Hint; he
wont), we don't have a case here. It doesn't really matter if its HTTP or HTTPS.
You also didn't really reply about the threat model.
If I understand correctly what Nicohood meant,
what could happen is that version X of systemd (or anything else) has a
well known vulnerability, fixed in X+1. X+1 is packaged, so anyone
up to date thinks "good I'm safe now". But since a man in the middle can
force to download version X (signed by the systemd maintainer so
considered "secure"), he can force you to download that version when you
create the package and you'll think you have the safe version while
having the unsafe one.
Okay, this I am genuinely curious about.
- the systemd repository cloned over the git:// protocol
- an annotated tag for systemd v233 signed by Lennart Poettering.
- an annotated tag for systemd v232 signed by Lennart Poettering.
- a man in the middle attack
- `git verify-tag --raw v233` reports a GOODSIG with a VALIDSIG
${fingerprint} that matches with Lennart's known GPG fingerprint as
recorded in validpgpkeys
And as a result, when I run the git command `git checkout
refs/tags/v233`, I am tricked into getting v232 instead which contains a
vulnerability. Also, I wouldn't be alerted by the verbose printing of
the systemd version which happens during the boot process, nor by
$systemd_binary --version
...
Because I don't think git works that way, but I am willing to be proven
wrong. Also I bet the git developers would be fascinated to hear the
details, you might even get some sort of bounty for successfully hacking
git like that.
On the other hand,
the systemd-stable repo doesn't have signed tags (or commits) and Arch
is probably going to move to that since it has post-release fixes for
regressions and bugs.
--
damjan
Ralf Mardorf
2017-07-03 07:12:20 UTC
Permalink
Raw Message
Post by NicoHood
I've checked the links and while those suggestions are a bit harsh,
* btrfs-progs can use stronger hashes.
Hi,

the subject doesn't mention that "btrfs-progs can use stronger
hashes", the subject actually is "Sébastien Luttringer and Tobias
Powalowski". If you want to discuss a possible issue, open a new thread
for e.g. "btrfs-progs can use stronger hashes".

I didn't care about the links, since even without Eli's hint it was
clear that this person is a known spammer.

Florian has moderated her/his new account. Next time we simply should
Post by NicoHood
He reminds me a bit of Torvalds, from what I've heard.
I haven't heard rumours about Linus Torvalds using disposable emails.
Perhaps "User <registrationhell..." is Linus Torvalds ;).

Regards,
Ralf
--
Vote for apulse!
echo $(w3m https://aur.archlinux.org/packages/apulse |grep 'Votes: ')
Votes: 82 Updated: Mon Jul 3 09:12:18 CEST 2017
Loading...