unsigned repos?

[HW42]

Hi,

it seems that while the rpms are signed correctly the repository
metadata isn't signed (the qubes repos and the fedora repo).

I think this is a real problem. It enables two kind attacks:
- an attacker can silently (i.e. without yum warnings) hide updates.
- the xml parser and sqlite is added to the TCB. Especially sqlite is
probably not designed for parsing untrusted data.

It seems that yum provides the functionality of verification of the
repo metadata (repo_gpgcheck in yum.repos). But nether the qubes repo
nor the fedora repo provides the needed repomd.xml.asc

HW42

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

HW42:

Interesting point.
Is there some kind of "not older than" that can be configured somehow?
(to prevent an attacker from replaying old signed repo files?)

Did you also file a fedora bug already?



-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJT7cVmAAoJEG58zmw5nc+vDTIP/AjG8Fi5AH7LHfXSaoEvkYdH
kwwqhyj5dSbVmfkEI2fzWRO4Gks3iz+xQrbNve+xHuNNyJ7lfP54NavBuzNqlBXU
DGuqRU9FeugquSenMVJYlFp8dQ6JReC21a8zkyq6BTpd57lmjquM708rBDrX00rn
8emBJo4wLdltRtjUw7zZ7ZqZY0+23xCekFXTG0/na/zd8QbB2py4kfdyFcX9F7V8
hxgEr+rGng7T+Ihk+zNyZo5ERbSW38vK7deB6F7CL8c69A3lx3evBzaNld7xQwYz
aCc9zc2Gyjk4iHR6YbcSTLks4E8psmffEmxz2rvJUW5Ie5T3N1T9HEf/XFTwLkvR
DcJl5hrivyGS4u56PDo9XQK78oC0m6bykiY2RFqVo2VTb3Do2FEIZM7CfbYRDl4F
wNXC+3N/aUuP0R9ZJro7DKvY1FN6OL+CQsxufqh7F/IImUAqKfmw6LQSC2lv5hmF
egDk97OK7O05Iv2JwaZGBJGg+dveBpSARSbnvYxbAGMlX1jopJWoNlpgaiRP/GDp
DJkqCp0vp3MQnX8Zl11w2Km1/aA+YZPMBfHq43USv2goMlbr8sndJJjLa5AO088j
oP4QadMI2sWeGAZMVngJf5JYysa/LN+fceLWSp8q7Au8rtcwdDr1a0eDIWlKhXgT
8C0xbug6CRTBvrbUK8zN
=q5vz
-----END PGP SIGNATURE-----

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Joonas Lehtonen:

> HW42:
>> it seems that while the rpms are signed correctly the repository
>> metadata isn't signed (the qubes repos and the fedora repo).
>
>> I think this is a real problem. It enables two kind attacks: -
>> an attacker can silently (i.e. without yum warnings) hide
>> updates. - the xml parser and sqlite is added to the TCB.
>> Especially sqlite is probably not designed for parsing untrusted
>> data.
>
>> It seems that yum provides the functionality of verification of
>> the repo metadata (repo_gpgcheck in yum.repos). But nether the
>> qubes repo nor the fedora repo provides the needed
>> repomd.xml.asc
>
> Interesting point. Is there some kind of "not older than" that can
> be configured somehow? (to prevent an attacker from replaying old
> signed repo files?)

There is 'metadata_expire', but I'm not quite sure whether this would
look at the timestamp of the gpg signature or just measure the time
when the file was last fetched.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJT7clRAAoJEG58zmw5nc+vPr4QANViIYE2VNgBSchCPLDdF0HN
lqG3rXSZ77p+0/uOE2am727DzroKsGwbZ8R3bcRVxaDUSWz0sG4eXny9oQpWhL5E
Q31OObthpFhiD2Xfh91wb5roBrmfQ5q2T7naG9On28EVQyCEYRNdesPv5YkyhzJQ
+FUwzL9RE6OrugJfaOTH+NrjpOaWSD/CCj5cmb8GX4/D8M4ge6GsL2Yhy0fq8G32
RobvE1P9Ns1rJorGca8SBmPBlh6lTapf1Na5vzYpO4vnMgFHutp6YJocOSNxcI1j
s8VctpOhrNNTU4n8xwUZt76sz/4XtJlMrbYxKUM+LV3nB8kGxtDnkXKuGux/meHR
YHjEmytJktMC4/av15YrHdUzdAOEwLAHesWdi/fGUCxvTFOfYXtW+0U3O/qjBoK2
2jZl4SpTc1zvc4cbpMD0THJkldfO8fn74W7RYkFhf7mxINlRM1kd5QAlPO4LJOd1
iqEHk3WLDjZ2eVBfKNnh0w/i4i8u0IH6Ombm0yutctOLq0qB4v4Q3G7I1kdqN18q
wnmaVQjCKV6x3TndY0c603lvPMO1kMFxVNl/il7FP1Yh18IG7Y1k5/P1HNoCmSYU
K6UBT2Qmzk21BgxT5KYVWHx1C88zpz5a1x68R8qTU9SKuWQ/81iYlLDqcN5Av658
TD73w1gho2LR4FfFKbRX
=YNdQ
-----END PGP SIGNATURE-----

[Joanna Rutkowska]

On 08/15/14 10:31, Joonas Lehtonen wrote:
> HW42:
>> it seems that while the rpms are signed correctly the repository
>> metadata isn't signed (the qubes repos and the fedora repo).
>
>> I think this is a real problem. It enables two kind attacks: - an
>> attacker can silently (i.e. without yum warnings) hide updates. -
>> the xml parser and sqlite is added to the TCB. Especially sqlite
>> is probably not designed for parsing untrusted data.
>
>> It seems that yum provides the functionality of verification of
>> the repo metadata (repo_gpgcheck in yum.repos). But nether the
>> qubes repo nor the fedora repo provides the needed repomd.xml.asc
>
> Interesting point.
> Is there some kind of "not older than" that can be configured somehow?
> (to prevent an attacker from replaying old signed repo files?)
>
> Did you also file a fedora bug already?
>
>
>
>

The attacker can always DoS the update process -- in the simplest
example by cutting off ones internet connection. But I'm pretty sure
that you/rpm won't allow for package downgrade, version-wise, no matter
what the repo metadata says.

The other problem you mentioned is more concerning, but there is little
we could about it. First, because we still need to support the upstream
updates from Fedora, second because even if we knew yum uses gpg -v
first, this wouldn't necessarily mean we're safe (google the thread
where we were discussing handling of incoming backups from untrusted
usbvm and how we decided not to use gpg for verification).

Note however, the the above problem doesn't apply to Dom0 updates,
because the repo metadata parsing is done by the updatesvm, not Dom0 --
see: https://wiki.qubes-os.org/wiki/Dom0SecureUpdates

Actually, I just thought that we could perhaps use the every same
mechanism as we use for Dom0 updating to also install updates for (all)
the template(s). This way we could also get rid of the yum proxy and
disable networking completely for the templates. What do you think Marek?

Thanks,
joanna.

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Joanna Rutkowska:

> The attacker can always DoS the update process -- in the simplest
> example by cutting off ones internet connection.

I believe HW42 was primarily concerned about an attacker blocking
updates silently ("without [causing] yum warnings"). Blocking
downloads completely will certainly generate some warning/error messages.

> But I'm pretty sure that you/rpm won't allow for package downgrade,
> version-wise, no matter what the repo metadata says.

HW42's described scenario will not result in your client installing an
older version that it already has, but it might prevent you from
installing a newer version than you already have because yum doesn't
know about the newer version. I believe this is feasible, but to know
for sure you would have to try it out.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJT7c+rAAoJEG58zmw5nc+vOwkP/jUI4AtsuUXoEwJIG3NkwLqE
WWLCeTpgmZTv+OGfQelZR7Uv4Ln+v2EU4gF9FK3oJ036fqo1E9vu9FaLktan+cyz
r8JblLoOG7j2Px1/ocmUz7506yBI0w0OMN2LuFWBp3mk1x266V3KQ1dxO1AuBO0t
rt9SRHB4h1FhU4fx2WZLIS/HTFk9aZdQyaLVPSSV5Zsi0Y78m7ndTioYqGpHQxeO
plfKZmQFl+YPhNh9enqHj7fAxd6ObkQ2fUpyY84dBz5NtidSLmuCfvh5Q50DhiGk
31uC5QhGmFT+eNoXqO6Oxoway0B74lEgyMxne0hS/Bjnq/QV9pe9b9UC57sbgmE0
rflACLoKx/TRVm1mFCHLSzHMGdWbShw0VzkRUMuXzL9C+X4gW6c5iu2aaNEKGOmZ
rOkXQy1zb9SRO0NBtQDNGq7JgG2HQLpEBwyU/pV7qe8pNMK3FBOK+qHXP1XcuQr2
Pp/xrEzaWTo0ZPSwGl8TSpgThu/a/YL+IlYQIDR5UX/e0gkBV6eJ92u2GH8cnKY7
66hbZpRHCegemKiYkYVEJps94T0aXKTBZREqY2mtGGCH2mLDol8lLLPVrgQSM12l
54zvWXYn07JTnPnfey9XAW4hMpJ9gi9zZH2NUfZaoNUjI/O5IpfedVU8oYzfGkoI
pZh6nDk66sXoCAo+4g/r
=mo8B
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

On 15.08.2014 11:15, Joonas Lehtonen wrote:
> Joanna Rutkowska:
>> The attacker can always DoS the update process -- in the simplest
>> example by cutting off ones internet connection.
>
> I believe HW42 was primarily concerned about an attacker blocking
> updates silently ("without [causing] yum warnings"). Blocking
> downloads completely will certainly generate some warning/error messages.

Ok, so attacker can simply provide you an old metadata. Do you expect us to
upload new "metadata valid until X" file every 2 weeks? This must be done
manually, because we don't want to store signing key on any server.

>> But I'm pretty sure that you/rpm won't allow for package downgrade,
>> version-wise, no matter what the repo metadata says.
>
> HW42's described scenario will not result in your client installing an
> older version that it already has, but it might prevent you from
> installing a newer version than you already have because yum doesn't
> know about the newer version. I believe this is feasible, but to know
> for sure you would have to try it out.
>

--

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Marek Marczykowski-Górecki]

There are some limitation in our update mechanism (the current
implementation), which are at least annoying for normal use. First of all, it
doesn't support groups, so one cannot install package group (@office, etc), or
update group (new package added to group will not be noticed). For dom0 we
workarounded it by having groups description file (comps.xml) copy. But we are
in control when our dom0 comps.xml is changed (very rarely), unlike Fedora
comps.xml one. There are also other metadata which we do not support for the
same reason (for example pkgtags, whatever it is).
The second problem is lack of deltarpm support, so update will require a lot
more data to download (deltarpm often save up to 80% bandwidth). This is a
problem for both user (longer update, especially on limited internet
connection) and mirror provided (more bandwidth used).
The third problem is the current implementation ask the user for continuation
when the packages are already downloaded. So the user will be able to abort
that 1GB packages installation only when they are already downloaded...
The fourth problem is lack of support for operations other than
install/update. For example search...
Also lack of GUI applications to install packages and updates.

Those are not big problems, but IMHO decreases user experience a lot.

[cprise]

On 08/15/14 05:19, Marek Marczykowski-Górecki wrote:
> On 15.08.2014 11:15, Joonas Lehtonen wrote:
>> Joanna Rutkowska:
>>> The attacker can always DoS the update process -- in the simplest
>>> example by cutting off ones internet connection.
>> I believe HW42 was primarily concerned about an attacker blocking
>> updates silently ("without [causing] yum warnings"). Blocking
>> downloads completely will certainly generate some warning/error messages.
> Ok, so attacker can simply provide you an old metadata. Do you expect us to
> upload new "metadata valid until X" file every 2 weeks? This must be done
> manually, because we don't want to store signing key on any server.

It sounds like the attacker could /alter/ the metadata and make it look
current, because it is unsigned?

If so, then specific packages could be held-back and the system would
appear to be updating normally because in fact most packages would still
get updates.

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Joonas Lehtonen:

> Did you also file a fedora bug already?

I did not find one so I went ahead:
https://bugzilla.redhat.com/show_bug.cgi?id=1130491

Related:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=569
https://trac.torproject.org/projects/tor/ticket/12871

Missing: adobe repo

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJT7fiAAAoJEG58zmw5nc+vhtEQALJCWYiGeIUfYerUwB9zJbwr
w1h+K5MAqZStW1NdseOBW3EYZfx92lrXyfhb8vJ6nBmg8wCcCK/VRrSljRmwH2c2
WGot6e+0phl+hn/5B45nosDVrNbA/LK70ug95zPbhrU4gvgA4/Sr5HLgi1R7e5BU
EYRQgsr3f/dpVBj2kST9uXDCJHpguW/cp6Hoy0+Kz/hVvSdwhTrEsEzDHwG0VKMb
ZDIzckxwqk782CgxOOC1fgJrJPfzokoelrJ0y7wWTbpBPEdgdSbxzXapn2Q2AFrA
eRicWsndQ+6JyWXU2acbE+bpdVDcGSJLQrhxgjzDSP6MbzEkcWDya+RJs7UM/1j9
IiogtEDPxDPJQxm3Ey8SopQOP6hFrWvpv79sXlpxN8aq/u5mMEMSRcCKzJAmTPo0
PRYRbLHZuowba48hxFLcP4YVCD626st4b5CUxgTfq/rIr8GwkJ64GnL/sodDXniu
LQtEDniMLfKBSpAToT2KJ95Il6JvRxmcPEpPwvqXvnRLW2xJr1ftHWEJrMHWfP9i
eQ8gYtRwB/eButkwnf8NdDFzX10K8D4bPAGKzBbc+drjRZymg8J5a5PvwJD4QRh5
H4tZAtMzTuag9RfSvSQ/SBJFlISY/5GwwrkWLn9ILCBF+6S8rt8jM8NIgjuH8CPF
itR23OvLM6ZcecxVKTPq
=lTDa
-----END PGP SIGNATURE-----

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:

> Ok, so attacker can simply provide you an old metadata. Do you
> expect us to upload new "metadata valid until X" file every 2
> weeks?

This is not about whether I have certain expectations or not, after
all I'm in no position to "expect" stuff. It is about whether ITL
considers [1] to be a risk worthwhile addressing or not.

[1] https://lwn.net/Articles/327847/

> This must be done manually, because we don't want to store signing
> key on any server.

It would be really surprising to me if you would keep private package
signing keys on servers ;)
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJT7fyUAAoJEG58zmw5nc+vn3kP/Az2KL+TOG0okjRvvm0wC9Kk
eKahfDW+Uo6KI1RNVOdVa8nIEN3CjhNX2eI47LfVofKRxXN0siphWuO9R2ihBDD3
g5Oph96q+FCX9VWloIDR6rCd2r5xQbU1j9aGi2l2p4f0otQY0GBbAMfnMKq3Zq0C
MXRJyLLMHsiqGF3TgmpfTaZvfJvaIIqRgfJ7uZE103gAwgJrdkQiEutwY3b3DUOd
9vF/yF9H0xb+rcLSzQj29tweEo5syl8nz+YIMmQwLYrxyq9BZ8DWIP9UxYrbHnJP
n1bmfaGnhv+G6sMy2bnsvEcTo5w4+xw0srIJGDA6PX5mB03Kx3nD5aOyHSRmQvfP
tl4BEsvLHEMC0niHllhjx0fmo7vbLN6BfFg5Rne/V0ZcZuFuvq/CBM4l5DLC954o
iAlBxSkMuwngH7dWAt5uENQdi4cfUCYF4sEUsK6nNxLhgqsCH2FNL1vaVppbLW+R
VqWsYt+HgFwtBklYq/D6OfJPLBrqyCHl1eZNuCzuyVRLxvl2KmARp4lqUFlhl+UA
AZNxEGuoMGLtjSj6phDuJNyvosB16dPFnGvjCZZ8IrAOSz37Vd7A+axWRu16E/fI
j4J6Ga/nXaF88NsnuFM4mTe6F5A9hpdeuvwjlHKPAfANm1/R6r0jEL0mxLf8AM1k
loQhPz8TKWjEbewUt3Wh
=CmYx
-----END PGP SIGNATURE-----

[cprise]

On 08/15/14 08:27, Joonas Lehtonen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Marek Marczykowski-Górecki:
>> Ok, so attacker can simply provide you an old metadata. Do you
>> expect us to upload new "metadata valid until X" file every 2
>> weeks?
> This is not about whether I have certain expectations or not, after
> all I'm in no position to "expect" stuff. It is about whether ITL
> considers [1] to be a risk worthwhile addressing or not.
>
> [1] https://lwn.net/Articles/327847/

This would be another reason to switch to Debian or Ubuntu-based templates.

[HW42]

Am Fri, 15 Aug 2014 10:49:02 +0200
schrieb Joanna Rutkowska <joa...@invisiblethingslab.com>:

Can someone point me to this thread? I was unable to find it.

[Axon]

HW42:

https://groups.google.com/d/topic/qubes-devel/TQr_QcXIVww/discussion

via

https://qubes-os.org/wiki/BackupRestore#TroubleshootingandTechnicalDetails

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

HW42:

> it seems that while the rpms are signed correctly the repository
> metadata isn't signed (the qubes repos and the fedora repo).

[...]

> But nether the qubes repo nor the fedora repo provides the needed
> repomd.xml.asc

The Qubes repo is actually more vulnerable to MITM attacks than Fedora
repos, because Fedora fetches the hash of repomd.xml via HTTPS [1]
before using repomd.xml (fetched via HTTP). I did not test the
implementation.

Going to file it as a bug.

[1]
https://lists.fedoraproject.org/pipermail/users/2014-August/452705.html

PS: It is obvious that the protection provided by HTTPS is less safe
than GPG signed repomd.xml but still better than no protection at all.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJT8JRFAAoJEG58zmw5nc+vHPEP/1g7fEVex1n04dIcZGQYJ2PW
cXZWY/ABj6qcjXREOoUjlFt6AfGgq6cq13I2VlXIsCmG1zm0oNN51RjSLOgqYYYF
Ld0xGrXb64RXClsk8swDmeMbIqIdun6L2pMDRzU2s8cFPYJzXYWaBsIm4fNRxDkI
r/LUEoONKZ1hz8RsMR8qG6oGBUfvZqUJYdyjE+KSMD1Baew9qJi9dCSxDBO5tGeR
w5KTLRLq/HBrDswzMBotr9IqGSV9+sTq9Xr9aTDRrSVK3vrtyD7Uk+huTOeHu/Z0
24SKwQHPjmOSwRlHZ8OC0dALUE8P94Orp585E7QubGEmTAg85bEDqne7wdkk+XTo
rclA8JSzCisE2rZTfBhNVQgxysaAcblfigT9nmeATN1HeLjxkdiItoQsR++vWMs9
51IQ4r4OUvazUfWH1Afx+n9cMb8SonTJL5Fm1vyit1pk6IXeaFcLXxBl9i26vQ0Z
l3qptSBlOaOcVz5EzSvWi/MmhSNrpuANmVN5Q5oGNHGFstUmzfBp3aSv1DRuF26y
Q1rK3QdbbbrHJYrnsyLvLt2s5pM8RFVPKYpGOOUtszE0CUoWEkQatuspbXWe7ApX
mxtmOJ3+K03LiXx1MPS3HbEVkRAdxOl4DKmly8nu8gqPJX4xLF4L32Z3379upNhP
22HBo3AjBCfhQqYLMYDV
=FfH0
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

On 17.08.2014 13:38, Joonas Lehtonen wrote:
> HW42:
>> it seems that while the rpms are signed correctly the repository
>> metadata isn't signed (the qubes repos and the fedora repo).
> [...]
>> But nether the qubes repo nor the fedora repo provides the needed
>> repomd.xml.asc
>
> The Qubes repo is actually more vulnerable to MITM attacks than Fedora
> repos, because Fedora fetches the hash of repomd.xml via HTTPS [1]
> before using repomd.xml (fetched via HTTP). I did not test the
> implementation.
>
> Going to file it as a bug.
>
> [1]
> https://lists.fedoraproject.org/pipermail/users/2014-August/452705.html

I've created this ticket:
https://wiki.qubes-os.org/ticket/891

Which still doesn't mean we will implement this. But at least have it
registered in bugtracker.

> PS: It is obvious that the protection provided by HTTPS is less safe
> than GPG signed repomd.xml but still better than no protection at all.

As Joanna already said, it is logistically hard to achieve signed metadata.

[cprise]

On 09/04/14 19:44, Marek Marczykowski-Górecki wrote:
> On 17.08.2014 13:38, Joonas Lehtonen wrote:
>> HW42:
>>> it seems that while the rpms are signed correctly the repository
>>> metadata isn't signed (the qubes repos and the fedora repo).
>> [...]
>>> But nether the qubes repo nor the fedora repo provides the needed
>>> repomd.xml.asc
>> The Qubes repo is actually more vulnerable to MITM attacks than Fedora
>> repos, because Fedora fetches the hash of repomd.xml via HTTPS [1]
>> before using repomd.xml (fetched via HTTP). I did not test the
>> implementation.
>>
>> Going to file it as a bug.
>>
>> [1]
>> https://lists.fedoraproject.org/pipermail/users/2014-August/452705.html
> I've created this ticket:
> https://wiki.qubes-os.org/ticket/891
>
> Which still doesn't mean we will implement this. But at least have it
> registered in bugtracker.
>
>> PS: It is obvious that the protection provided by HTTPS is less safe
>> than GPG signed repomd.xml but still better than no protection at all.
> As Joanna already said, it is logistically hard to achieve signed metadata.
>

FYI, these are some free/gratis distros with signed repo metadata:

Debian
Ubuntu
Mint
OpenSUSE
CentOS

Fedora is the only other one I know of that is unsigned.