Hi, 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 time, CVE-2019-15513.
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. https://www.cvedetails.com/cve/CVE-2019-15513/ The details are "described" in this pdf file which is partly in Mandarin: https://github.com/TeamSeri0us/pocs/blob/master/iot/morouter/motorola%E8%B7%AF%E7%94%B1%E5%99%A8%E6%96%87%E4%BB%B6%E8%A7%A3%E9%94%81%E6%BC%8F%E6%B4%9E.pdf This paper only looks at the disassembled binary even when the source is open source. 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: https://github.com/openwrt/packages/issues/1231 This problem was fixed by Yousong in this commits over 4 years ago: https://git.openwrt.org/?p=project/uci.git;a=commitdiff;h=19e29ffc15dbd958e8e6a648ee0982c68353516f This commit allows longer lines: https://git.openwrt.org/?p=project/uci.git;a=commitdiff;h=4b52bdbdbec3c84afeab5c3167e69f7c6012b2f3 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; UCI_TRAP_SAVE(ctx, done); stream = uci_open_stream(ctx, filename, NULL, SEEK_SET, flush, false); if (p) changes = uci_parse_delta(ctx, stream, p); UCI_TRAP_RESTORE(ctx); done: if (f) *f = stream; else if (stream) uci_close_stream(stream); return changes; } --------------------------------------------------------------- https://git.openwrt.org/?p=project/uci.git;a=blob;f=delta.c;h=459d2c7ddfd5d4443c24c02a76952d40319bb871;hb=556215152a216c179fe2ca7db9b1de7036ceda60#l289 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 cont...@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. Hauke
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel