[OpenWrt-Devel] CVE-2019-15513 analysis
hauke at hauke-m.de
Fri Nov 1 09:23:19 EDT 2019
At the prpl Summit 2019 I saw a slide with 4 CVEs which are filled
against OpenWrt and there was one listed I was not aware of at that
According to the CVE details page it was filled against OpenWrt on
23.8.2019 and OpenWrt was not informed before or after this was filled
against OpenWrt, we only saw this by luck.
The details are "described" in this pdf file which is partly in Mandarin:
This paper only looks at the disassembled binary even when the source is
Petr (ynezz) tried to reproduce this, but was not able to do so with a
recent OpenWrt. Later we found that this problem was fixed in OpenWrt
15.05.1 and later more than 4 years ago.
The problem was already reported here, but not as a security problem:
This problem was fixed by Yousong in this commits over 4 years ago:
This commit allows longer lines:
The problem was that uci_open_stream() opens the given filename and also
locks it with flock() so that other processes can not use it. In this
case the lock on the file is not released which causes a dead lock in
uci and something hangs, no code executing or something similar
possible, just one process hangs. This can normally only be called by root.
UCI makes use of setjmp() and longjmp() for error handling. When an
error occurs it jumps back to the save point. This is encapsulated in
UCI_TRAP_SAVE() and UCI_THROW(). longjmp() saves all the registers, so
variables which are stored in memory are not restored, but variables
stored in registers are restored to their old values.
When uci_getln() is called with a string of more than 4096 bytes it runs
into an error case and calls UCI_THROW() which jumps back to the last
save point, in this case to uci_load_delta_file(). In this description
it gets called in this way:
uci_load_delta_file() -> uci_parse_delta() -> uci_getln()
uci_load_delta_file() looked liked this:
/* returns the number of changes that were successfully parsed */
static int uci_load_delta_file(struct uci_context *ctx, struct
uci_package *p, char *filename, FILE **f, bool flush)
FILE *stream = NULL;
int changes = 0;
stream = uci_open_stream(ctx, filename, NULL, SEEK_SET, flush, false);
changes = uci_parse_delta(ctx, stream, p);
*f = stream;
else if (stream)
When uci_parse_delta() calls UCI_THROW() it jumps to done. The problem
is that stream is stored in a register and not on the stack because the
compiler thinks this is ok. Then stream will be restored to the original
value which is NULL and we loose the reference to the original stream
file pointer. uci_close_stream() will not be called and the file pointer
is not unlocked and also not closed.
This problem was fixed in OpenWrt 15.05.1.
The CVE says it does not need authentication, as far as I understand
this root permissions are needed to exploit this problem, it could also
be possible over Luci.
It could be that these Motorola CX2L MWR04L and MWR03 devices where this
problem was found use UCI in a different way in their vendor FW which
forked OpenWrt, but I do not have these devices, the source code or the
binaries of these devices.
If you find a security problem in OpenWrt please get in contact with us
at contact at openwrt.org preferable before publishing it, but at least
after you published it. I do not like it, when a CVE is just filled
without informing us. Do not assume that some random vendor in which
firmware you found this problem reports the problem back to us, normally
they only fork OpenWrt and do not care about upstream OpenWrt. If you
find a problem in OpenWrt please talk to OpenWrt!
If you see a CVE against OpenWrt and there is no communication on the
normal OpenWrt mailings about it, please ask on the public mailling list
if someone knows about this, this is already the 2. CVE filled against
OpenWrt where we did not got informed at all.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: OpenPGP digital signature
-------------- next part --------------
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel