applied various flaws (#1663893)

This commit is contained in:
Ondrej Dubaj 2019-03-21 09:04:54 +01:00
parent e46ee261c5
commit ab85643804
5 changed files with 203 additions and 1 deletions

View File

@ -0,0 +1,34 @@
From c7746e62d09b94ddcf98b36fa3ddcfdb20c4b40b Mon Sep 17 00:00:00 2001
From: Daniel Axtens <dja@axtens.net>
Date: Tue, 20 Nov 2018 17:56:29 +1100
Subject: [PATCH] Avoid a double-free when a window size of 0 is specified
new_size can be 0 with a malicious or corrupted RAR archive.
realloc(area, 0) is equivalent to free(area), so the region would
be free()d here and the free()d again in the cleanup function.
Found with a setup running AFL, afl-rb, and qsym.
---
libarchive/archive_read_support_format_rar.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/libarchive/archive_read_support_format_rar.c b/libarchive/archive_read_support_format_rar.c
index 23452222..6f419c27 100644
--- a/libarchive/archive_read_support_format_rar.c
+++ b/libarchive/archive_read_support_format_rar.c
@@ -2300,6 +2300,11 @@ parse_codes(struct archive_read *a)
new_size = DICTIONARY_MAX_SIZE;
else
new_size = rar_fls((unsigned int)rar->unp_size) << 1;
+ if (new_size == 0) {
+ archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT,
+ "Zero window size is invalid.");
+ return (ARCHIVE_FATAL);
+ }
new_window = realloc(rar->lzss.window, new_size);
if (new_window == NULL) {
archive_set_error(&a->archive, ENOMEM,
--
2.17.1

View File

@ -0,0 +1,75 @@
From 22700942fec895b2d3e5ed6741756deb8666eaae Mon Sep 17 00:00:00 2001
From: Daniel Axtens <dja@axtens.net>
Date: Tue, 4 Dec 2018 00:55:22 +1100
Subject: [PATCH] rar: file split across multi-part archives must match
Fuzzing uncovered some UAF and memory overrun bugs where a file in a
single file archive reported that it was split across multiple
volumes. This was caused by ppmd7 operations calling
rar_br_fillup. This would invoke rar_read_ahead, which would in some
situations invoke archive_read_format_rar_read_header. That would
check the new file name against the old file name, and if they didn't
match up it would free the ppmd7 buffer and allocate a new
one. However, because the ppmd7 decoder wasn't actually done with the
buffer, it would continue to used the freed buffer. Both reads and
writes to the freed region can be observed.
This is quite tricky to solve: once the buffer has been freed it is
too late, as the ppmd7 decoder functions almost universally assume
success - there's no way for ppmd_read to signal error, nor are there
good ways for functions like Range_Normalise to propagate them. So we
can't detect after the fact that we're in an invalid state - e.g. by
checking rar->cursor, we have to prevent ourselves from ever ending up
there. So, when we are in the dangerous part or rar_read_ahead that
assumes a valid split, we set a flag force read_header to either go
down the path for split files or bail. This means that the ppmd7
decoder keeps a valid buffer and just runs out of data.
Found with a combination of AFL, afl-rb and qsym.
---
libarchive/archive_read_support_format_rar.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/libarchive/archive_read_support_format_rar.c b/libarchive/archive_read_support_format_rar.c
index 6f419c27..a8cc5c94 100644
--- a/libarchive/archive_read_support_format_rar.c
+++ b/libarchive/archive_read_support_format_rar.c
@@ -258,6 +258,7 @@ struct rar
struct data_block_offsets *dbo;
unsigned int cursor;
unsigned int nodes;
+ char filename_must_match;
/* LZSS members */
struct huffman_code maincode;
@@ -1560,6 +1561,12 @@ read_header(struct archive_read *a, struct archive_entry *entry,
}
return ret;
}
+ else if (rar->filename_must_match)
+ {
+ archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT,
+ "Mismatch of file parts split across multi-volume archive");
+ return (ARCHIVE_FATAL);
+ }
rar->filename_save = (char*)realloc(rar->filename_save,
filename_size + 1);
@@ -2933,12 +2940,14 @@ rar_read_ahead(struct archive_read *a, size_t min, ssize_t *avail)
else if (*avail == 0 && rar->main_flags & MHD_VOLUME &&
rar->file_flags & FHD_SPLIT_AFTER)
{
+ rar->filename_must_match = 1;
ret = archive_read_format_rar_read_header(a, a->entry);
if (ret == (ARCHIVE_EOF))
{
rar->has_endarc_header = 1;
ret = archive_read_format_rar_read_header(a, a->entry);
}
+ rar->filename_must_match = 0;
if (ret != (ARCHIVE_OK))
return NULL;
return rar_read_ahead(a, min, avail);
--
2.17.1

View File

@ -0,0 +1,46 @@
From 3800cdbaf04b775b091b4b88a40933a2aa800a90 Mon Sep 17 00:00:00 2001
From: Daniel Axtens <dja@axtens.net>
Date: Tue, 4 Dec 2018 14:29:42 +1100
Subject: [PATCH] Skip 0-length ACL fields
Currently, it is possible to create an archive that crashes bsdtar
with a malformed ACL:
Program received signal SIGSEGV, Segmentation fault.
archive_acl_from_text_l (acl=<optimised out>, text=0x7e2e92 "", want_type=<optimised out>, sc=<optimised out>) at libarchive/archive_acl.c:1726
1726 switch (*s) {
(gdb) p n
$1 = 1
(gdb) p field[n]
$2 = {start = 0x0, end = 0x0}
Stop this by checking that the length is not zero before beginning
the switch statement.
I am pretty sure this is the bug mentioned in the qsym paper [1],
and I was able to replicate it with a qsym + AFL + afl-rb setup.
[1] https://www.usenix.org/conference/usenixsecurity18/presentation/yun
---
libarchive/archive_acl.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/libarchive/archive_acl.c b/libarchive/archive_acl.c
index fe42b9b8..cb23ad88 100644
--- a/libarchive/archive_acl.c
+++ b/libarchive/archive_acl.c
@@ -1711,6 +1711,11 @@ archive_acl_from_text_l(struct archive_acl *acl, const char *text,
st = field[n].start + 1;
len = field[n].end - field[n].start;
+ if (len == 0) {
+ ret = ARCHIVE_WARN;
+ continue;
+ }
+
switch (*s) {
case 'u':
if (len == 1 || (len == 4
--
2.17.1

View File

@ -0,0 +1,40 @@
From 1df1642b5f9fa94a8443457bd1b7112362082f6b Mon Sep 17 00:00:00 2001
From: Daniel Axtens <dja@axtens.net>
Date: Tue, 4 Dec 2018 16:33:42 +1100
Subject: [PATCH] warc: consume data once read
The warc decoder only used read ahead, it wouldn't actually consume
data that had previously been printed. This means that if you specify
an invalid content length, it will just reprint the same data over
and over and over again until it hits the desired length.
This means that a WARC resource with e.g.
Content-Length: 666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666665
but only a few hundred bytes of data, causes a quasi-infinite loop.
Consume data in subsequent calls to _warc_read.
Found with an AFL + afl-rb + qsym setup.
---
libarchive/archive_read_support_format_warc.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/libarchive/archive_read_support_format_warc.c b/libarchive/archive_read_support_format_warc.c
index e8753853..e8fc8428 100644
--- a/libarchive/archive_read_support_format_warc.c
+++ b/libarchive/archive_read_support_format_warc.c
@@ -386,6 +386,11 @@ _warc_read(struct archive_read *a, const void **buf, size_t *bsz, int64_t *off)
return (ARCHIVE_EOF);
}
+ if (w->unconsumed) {
+ __archive_read_consume(a, w->unconsumed);
+ w->unconsumed = 0U;
+ }
+
rab = __archive_read_ahead(a, 1U, &nrd);
if (nrd < 0) {
*bsz = 0U;
--
2.17.1

View File

@ -2,7 +2,7 @@
Name: libarchive
Version: 3.3.3
Release: 5%{?dist}
Release: 6%{?dist}
Summary: A library for handling streaming archive formats
License: BSD
@ -12,6 +12,10 @@ Source0: http://www.libarchive.org/downloads/%{name}-%{version}.tar.gz
Patch0: libarchive-3.3.3-covscan-2018.patch
Patch1: libarchive-3.1.2-CVE-2019-1000019.patch
Patch2: libarchive-3.1.2-CVE-2019-1000020.patch
Patch3: libarchive-3.3.3-CVE-2018-1000877.patch
Patch4: libarchive-3.3.3-CVE-2018-1000878.patch
Patch5: libarchive-3.3.3-CVE-2018-1000879.patch
Patch6: libarchive-3.3.3-CVE-2018-1000880.patch
BuildRequires: automake
BuildRequires: bison
@ -215,6 +219,9 @@ run_testsuite
%changelog
* Thu Mar 19 2019 Ondrej Dubaj <odubaj@redhat.com> - 3.3.3-6
- applied various flaws (#1663893)
* Thu Mar 19 2019 Ondrej Dubaj <odubaj@redhat.com> - 3.3.3-5
- applied CVE patches (#1690071)