shaba/ostree
1
0
Fork 0
mirror of https://github.com/ostreedev/ostree.git synced 2024-12-23 21:35:26 +03:00
Code Issues Projects Releases Wiki Activity
12cafbcf8d
ostree/tests/test-pull-large-metadata.sh

44 lines
1.5 KiB
Bash
Raw Normal View History

Limit metadata to 10 MiB If fetching GPG-signed commits over plain HTTP, a MitM attacker can fill up the drive of targets by simply returning an enormous stream for the commit object. Related to this, an attacker can also cause OSTree to perform large memory allocations by returning enormous GVariants in the metadata. This helps close that attack by limiting all metadata objects to 10 MiB, so the initial fetch will be truncated. But now the attack is only slightly more difficult as the attacker will have to return a correctly formed commit object, then return a large stream of < 10 MiB dirmeta/dirtree objects. https://bugzilla.gnome.org/show_bug.cgi?id=725921
2014-04-25 23:14:42 +04:00
#!/bin/bash
#
# Copyright (C) 2011 Colin Walters <walters@verbum.org>
#
Add SPDX-License-Identifier to source files SPDX License List is a list of (common) open source licenses that can be referred to by a “short identifier”. It has several advantages compared to the common "license header texts" usually found in source files. Some of the advantages: * It is precise; there is no ambiguity due to variations in license header text * It is language neutral * It is easy to machine process * It is concise * It is simple and can be used without much cost in interpreted environments like java Script, etc. * An SPDX license identifier is immutable. * It provides simple guidance for developers who want to make sure the license for their code is respected See http://spdx.org for further reading. Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Closes: #1439 Approved by: cgwalters
2018-01-30 22:26:26 +03:00
# SPDX-License-Identifier: LGPL-2.0+
#
Limit metadata to 10 MiB If fetching GPG-signed commits over plain HTTP, a MitM attacker can fill up the drive of targets by simply returning an enormous stream for the commit object. Related to this, an attacker can also cause OSTree to perform large memory allocations by returning enormous GVariants in the metadata. This helps close that attack by limiting all metadata objects to 10 MiB, so the initial fetch will be truncated. But now the attack is only slightly more difficult as the attacker will have to return a correctly formed commit object, then return a large stream of < 10 MiB dirmeta/dirtree objects. https://bugzilla.gnome.org/show_bug.cgi?id=725921
2014-04-25 23:14:42 +04:00
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2 of the License, or (at your option) any later version.
#
# This library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public
Update FSF license notices to use URL instead of address
2021-12-07 04:20:55 +03:00
# License along with this library. If not, see <https://www.gnu.org/licenses/>.
Limit metadata to 10 MiB If fetching GPG-signed commits over plain HTTP, a MitM attacker can fill up the drive of targets by simply returning an enormous stream for the commit object. Related to this, an attacker can also cause OSTree to perform large memory allocations by returning enormous GVariants in the metadata. This helps close that attack by limiting all metadata objects to 10 MiB, so the initial fetch will be truncated. But now the attack is only slightly more difficult as the attacker will have to return a correctly formed commit object, then return a large stream of < 10 MiB dirmeta/dirtree objects. https://bugzilla.gnome.org/show_bug.cgi?id=725921
2014-04-25 23:14:42 +04:00
tests: Use "bash strict mode" I noticed in the static deltas tests, there were some tests that should have been under `-o pipefail` to ensure we properly propagate errors. There were a few places where we were referencing undefined variables. Overall, this is clearly a good idea IMO.
2016-01-27 19:44:10 +03:00
set -euo pipefail
Limit metadata to 10 MiB If fetching GPG-signed commits over plain HTTP, a MitM attacker can fill up the drive of targets by simply returning an enormous stream for the commit object. Related to this, an attacker can also cause OSTree to perform large memory allocations by returning enormous GVariants in the metadata. This helps close that attack by limiting all metadata objects to 10 MiB, so the initial fetch will be truncated. But now the attack is only slightly more difficult as the attacker will have to return a correctly formed commit object, then return a large stream of < 10 MiB dirmeta/dirtree objects. https://bugzilla.gnome.org/show_bug.cgi?id=725921
2014-04-25 23:14:42 +04:00
. $(dirname $0)/libtest.sh
tree-wide: Replace archive-z2 with archive In almost all places. There are just a few exceptions; one tricky bit for example is that the repo config must still have `mode=archive-z2`, since `archive` used to mean something else. (We could very likely just get rid of that check, but eh, later). I also added a test that one can still do `ostree repo init --mode=archive-z2`. Closes: #1125 Approved by: jlebon
2017-09-01 23:15:33 +03:00
setup_fake_remote_repo1 "archive"
Limit metadata to 10 MiB If fetching GPG-signed commits over plain HTTP, a MitM attacker can fill up the drive of targets by simply returning an enormous stream for the commit object. Related to this, an attacker can also cause OSTree to perform large memory allocations by returning enormous GVariants in the metadata. This helps close that attack by limiting all metadata objects to 10 MiB, so the initial fetch will be truncated. But now the attack is only slightly more difficult as the attacker will have to return a correctly formed commit object, then return a large stream of < 10 MiB dirmeta/dirtree objects. https://bugzilla.gnome.org/show_bug.cgi?id=725921
2014-04-25 23:14:42 +04:00
echo '1..1'
# Overwrite the commit object with 20 M of
cd ${test_tmpdir}
tests: enforce ${CMD_PREFIX} on all ostree processes Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
2015-03-03 15:13:54 +03:00
rev=$(cd ostree-srv && ${CMD_PREFIX} ostree --repo=gnomerepo rev-parse main)
Limit metadata to 10 MiB If fetching GPG-signed commits over plain HTTP, a MitM attacker can fill up the drive of targets by simply returning an enormous stream for the commit object. Related to this, an attacker can also cause OSTree to perform large memory allocations by returning enormous GVariants in the metadata. This helps close that attack by limiting all metadata objects to 10 MiB, so the initial fetch will be truncated. But now the attack is only slightly more difficult as the attacker will have to return a correctly formed commit object, then return a large stream of < 10 MiB dirmeta/dirtree objects. https://bugzilla.gnome.org/show_bug.cgi?id=725921
2014-04-25 23:14:42 +04:00
dd if=/dev/zero bs=1M count=20 of=ostree-srv/gnomerepo/objects/$(echo $rev | cut -b 1-2)/$(echo $rev | cut -b 3-).commit
cd ${test_tmpdir}
mkdir repo
repo+tests: Add [core]disable-xattrs=true, use it on overlayfs There are a lot of things suboptimal about this approach, but on the other hand we need to get our CI back up and running. The basic approach is to - in the test suite, detect if we're on overlayfs. If so, set a flag in the repo, which gets picked up by a few strategic places in the core to turn on "ignore xattrs". I also had to add a variant of this for the sysroot work. The core problem here is while overlayfs will let us read and see the SELinux labels, it won't let us write them. Down the line, we should improve this so that we can selectively ignore e.g. `security.*` attributes but not `user.*` say. Closes: https://github.com/ostreedev/ostree/issues/758 Closes: #759 Approved by: jlebon
2017-03-24 17:35:59 +03:00
ostree_repo_init repo
Limit metadata to 10 MiB If fetching GPG-signed commits over plain HTTP, a MitM attacker can fill up the drive of targets by simply returning an enormous stream for the commit object. Related to this, an attacker can also cause OSTree to perform large memory allocations by returning enormous GVariants in the metadata. This helps close that attack by limiting all metadata objects to 10 MiB, so the initial fetch will be truncated. But now the attack is only slightly more difficult as the attacker will have to return a correctly formed commit object, then return a large stream of < 10 MiB dirmeta/dirtree objects. https://bugzilla.gnome.org/show_bug.cgi?id=725921
2014-04-25 23:14:42 +04:00
${CMD_PREFIX} ostree --repo=repo remote add --set=gpg-verify=false origin $(cat httpd-address)/ostree/gnomerepo
tests: enforce ${CMD_PREFIX} on all ostree processes Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
2015-03-03 15:13:54 +03:00
if ${CMD_PREFIX} ostree --repo=repo pull origin main 2>pulllog.txt 1>&2; then
Limit metadata to 10 MiB If fetching GPG-signed commits over plain HTTP, a MitM attacker can fill up the drive of targets by simply returning an enormous stream for the commit object. Related to this, an attacker can also cause OSTree to perform large memory allocations by returning enormous GVariants in the metadata. This helps close that attack by limiting all metadata objects to 10 MiB, so the initial fetch will be truncated. But now the attack is only slightly more difficult as the attacker will have to return a correctly formed commit object, then return a large stream of < 10 MiB dirmeta/dirtree objects. https://bugzilla.gnome.org/show_bug.cgi?id=725921
2014-04-25 23:14:42 +04:00
assert_not_reached "pull unexpectedly succeeded!"
fi
assert_file_has_content pulllog.txt "exceeded maximum"
tests: Port to glib-tap.mk, make `make check` run all of the tests OSTree's code for testing predates the `glib-tap.mk` making its way into GLib. Let's switch to it, as it provides a number of advantages. By far the biggest advantage is that `make check` can start to run most of the tests *in addition* to having them work installed. This commit keeps the installed tests working, but `make check` turns out to be really broken because...our TAP usage has bitrotted to say the least. Fix that all up. Do some hacks so that the tests work uninstalled as well - in particular, `glib-tap.mk` and the bits encoded into `g_test_build_filename()` assume *recursive* Automake (blah). Work around that by creating a symlink when installed to loop back.
2016-03-02 18:28:04 +03:00
echo "ok"
Reference in New Issue Copy Permalink