lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 8 May 2021 09:55:37 +0200
From: Gynvael Coldwind <gynvael@...dwind.pl>
To: Q C <cq674350529@...il.com>
Cc: fulldisclosure <fulldisclosure@...lists.org>
Subject: Re: [FD] Three vulnerabilities found in MikroTik's RouterOS

Got it! Thank you for the explanation!

On Sat, May 8, 2021 at 4:53 AM Q C <cq674350529@...il.com> wrote:

> Hi,
>
> In Mikrotik RouterOs, each user is assigned to a user group, which denotes
> the rights of this user. A group policy is a combination of individual
> policy items, and provides a convenient way to assign different permissions
> and access rights to different user classes.    (Reference:
> https://help.mikrotik.com/docs/display/ROS/User)
>
> Some common individual policy items are: web, winbox, read, write, reboot
> and so on. Among of them, reboot is treated as a separate permission. So an
> authenticated user may not have the permission to reboot the device.
>
> As to these vulnerabilities (or software bugs?), reboot permission is not
> required to trigger them. And they may pose an impact on the system
> services or even reboot the system. Of course, since authentication is
> still necessary to trigger them, they have a low impact.
>
> Thanks!
>
>
> Gynvael Coldwind <gynvael@...dwind.pl> 于2021年5月8日周六 上午12:09写道:
>
>> Hi,
>>
>> I might be missing something, but how are these considered
>> vulnerabilities?
>> My point is that these require authentication, and an already
>> authenticated user already has permissions to reboot the device anyway,
>> right?
>>
>> If the above assumption is correct, then there isn't really a security
>> boundary breach, so it would be a software bug, but not a vulnerability.
>> Or am I missing something?
>>
>> Thanks,
>> Gynvael
>>
>> On Fri, May 7, 2021 at 5:51 PM Q C <cq674350529@...il.com> wrote:
>>
>>> [update 2021/05/04] Three CVEs have been assigned to these
>>> vulnerabilities.
>>>
>>> CVE-2020-20215: Mikrotik RouterOs 6.44.6 (long-term tree) suffers from a
>>> memory corruption vulnerability in the /nova/bin/diskd process. An
>>> authenticated remote attacker can cause a Denial of Service due to
>>> invalid
>>> memory access.
>>>
>>> CVE-2020-20216: Mikrotik RouterOs 6.44.6 (long-term tree) suffers from a
>>> memory corruption vulnerability in the /nova/bin/graphing process. An
>>> authenticated remote attacker can cause a Denial of Service (NULL pointer
>>> dereference)
>>>
>>> CVE-2020-20213: Mikrotik RouterOs 6.44.5 (long-term tree) suffers from an
>>> stack exhaustion vulnerability in the /nova/bin/net process. An
>>> authenticated remote attacker can cause a Denial of Service due to
>>> overloading the systems CPU
>>>
>>>
>>>
>>> Q C <cq674350529@...il.com> 于2020年7月22日周三 下午8:11写道:
>>>
>>> > Advisory: three vulnerabilities found in MikroTik's RouterOS
>>> >
>>> >
>>> > Details
>>> > =======
>>> >
>>> > Product: MikroTik's RouterOS
>>> > Vendor URL: https://mikrotik.com/
>>> > Vendor Status: fixed version released
>>> > CVE: -
>>> > Credit: Qian Chen(@cq674350529) of Qihoo 360 Nirvan Team
>>> >
>>> >
>>> > Product Description
>>> > ==================
>>> >
>>> > RouterOS is the operating system used on the MikroTik's devices, such
>>> as
>>> > switch, router and access point.
>>> >
>>> >
>>> > Description of vulnerabilities
>>> > ==========================
>>> >
>>> > 1. Memory corruption vulnerability
>>> > The diskd process suffers from a memory corruption vulnerability. By
>>> > sending a crafted packet, an authenticated remote user can crash the
>>> diskd
>>> > process due to invalid memory access.
>>> >
>>> > Against stable 6.44.3, the poc resulted in the following crash dump.
>>> >
>>> >     # cat /rw/logs/backtrace.log
>>> >     2020.06.04-14:18:22.55@0:
>>> >     2020.06.04-14:18:22.55@0:
>>> >     2020.06.04-14:18:22.55@0: /nova/bin/diskd
>>> >     2020.06.04-14:18:22.55@0: --- signal=11
>>> > --------------------------------------------
>>> >     2020.06.04-14:18:22.55@0:
>>> >     2020.06.04-14:18:22.55@0: eip=0x776cd1db eflags=0x00010202
>>> >     2020.06.04-14:18:22.55@0: edi=0x08056760 esi=0x08056790
>>> > ebp=0x7fd40b78 esp=0x7fd40b6c
>>> >     2020.06.04-14:18:22.55@0: eax=0x0000001b ebx=0x776d54ec
>>> > ecx=0x776d54ec edx=0x20fe0010
>>> >     2020.06.04-14:18:22.55@0:
>>> >     2020.06.04-14:18:22.55@0: maps:
>>> >     2020.06.04-14:18:22.55@0: 08048000-08052000 r-xp 00000000 00:0c
>>> 1131
>>> >       /nova/bin/diskd
>>> >     2020.06.04-14:18:22.55@0: 77672000-776a7000 r-xp 00000000 00:0c
>>> 996
>>> >      /lib/libuClibc-0.9.33.2.so
>>> >     2020.06.04-14:18:22.55@0: 776ab000-776c5000 r-xp 00000000 00:0c
>>> 992
>>> >      /lib/libgcc_s.so.1
>>> >     2020.06.04-14:18:22.55@0: 776c6000-776d5000 r-xp 00000000 00:0c
>>> 976
>>> >      /lib/libuc++.so
>>> >     2020.06.04-14:18:22.55@0: 776d6000-776de000 r-xp 00000000 00:0c
>>> 982
>>> >      /lib/libubox.so
>>> >     2020.06.04-14:18:22.55@0: 776df000-7772b000 r-xp 00000000 00:0c
>>> 978
>>> >      /lib/libumsg.so
>>> >     2020.06.04-14:18:22.55@0: 77731000-77738000 r-xp 00000000 00:0c
>>> 990
>>> >      /lib/ld-uClibc-0.9.33.2.so
>>> >     2020.06.04-14:18:22.55@0:
>>> >     2020.06.04-14:18:22.55@0: stack: 0x7fd41000 - 0x7fd40b6c
>>> >     2020.06.04-14:18:22.55@0: ec 54 6d 77 1b 00 00 00 88 67 05 08 98
>>> 0b
>>> > d4 7f c6 c6 04 08 88 67 05 08 1b 00 00 00 10 00 fe 20
>>> >     2020.06.04-14:18:22.55@0: 10 00 fe 20 ec 54 6d 77 f0 ea 6d 77 08
>>> 0c
>>> > d4 7f 6d a9 6d 77 88 67 05 08 1b 00 00 00 05 00 00 00
>>> >     2020.06.04-14:18:22.55@0:
>>> >     2020.06.04-14:18:22.55@0: code: 0x776cd1db
>>> >     2020.06.04-14:18:22.55@0: 8b 00 8b 10 01 c2 83 c2 04 52 83 c0 04
>>> 50
>>> > ff 75
>>> >
>>> > This vulnerability was initially found in long-term 6.44.5, and has
>>> been
>>> > fixed in stable 6.47.
>>> >
>>> > 2. NULL pointer dereference vulnerability
>>> > The graphing process suffers from a memory corruption vulnerability. By
>>> > sending a crafted packet, an authenticated remote user can crash the
>>> > graphing process due to NULL
>>> > pointer dereference.
>>> >
>>> > Against stable 6.46.5, the poc resulted in the following crash dump.
>>> >
>>> >     # cat /rw/logs/backtrace.log
>>> >     2020.06.04-15:12:41.47@0:
>>> >     2020.06.04-15:12:41.47@0:
>>> >     2020.06.04-15:12:41.47@0: /nova/bin/graphing
>>> >     2020.06.04-15:12:41.47@0: --- signal=11
>>> > --------------------------------------------
>>> >     2020.06.04-15:12:41.47@0:
>>> >     2020.06.04-15:12:41.47@0: eip=0x080521e2 eflags=0x00010202
>>> >     2020.06.04-15:12:41.47@0: edi=0x080610a0 esi=0x08061cb8
>>> > ebp=0x7fa8acd8 esp=0x7fa8acb0
>>> >     2020.06.04-15:12:41.47@0: eax=0x08061db8 ebx=0x7fa8ad0c
>>> > ecx=0x00000000 edx=0x08061ce8
>>> >     2020.06.04-15:12:41.47@0:
>>> >     2020.06.04-15:12:41.47@0: maps:
>>> >     2020.06.04-15:12:41.47@0: 08048000-0805c000 r-xp 00000000 00:0c
>>> 1038
>>> >       /nova/bin/graphing
>>> >     2020.06.04-15:12:41.47@0: 77651000-77686000 r-xp 00000000 00:0c
>>> 964
>>> >      /lib/libuClibc-0.9.33.2.so
>>> >     2020.06.04-15:12:41.47@0: 7768a000-776a4000 r-xp 00000000 00:0c
>>> 960
>>> >      /lib/libgcc_s.so.1
>>> >     2020.06.04-15:12:41.47@0: 776a5000-776b4000 r-xp 00000000 00:0c
>>> 944
>>> >      /lib/libuc++.so
>>> >     2020.06.04-15:12:41.47@0: 776b5000-776bd000 r-xp 00000000 00:0c
>>> 950
>>> >      /lib/libubox.so
>>> >     2020.06.04-15:12:41.47@0: 776be000-7770a000 r-xp 00000000 00:0c
>>> 946
>>> >      /lib/libumsg.so
>>> >     2020.06.04-15:12:41.47@0: 7770d000-77717000 r-xp 00000000 00:0c
>>> 961
>>> >      /lib/libm-0.9.33.2.so
>>> >     2020.06.04-15:12:41.47@0: 7771c000-77723000 r-xp 00000000 00:0c
>>> 958
>>> >      /lib/ld-uClibc-0.9.33.2.so
>>> >     2020.06.04-15:12:41.47@0:
>>> >     2020.06.04-15:12:41.47@0: stack: 0x7fa8b000 - 0x7fa8acb0
>>> >     2020.06.04-15:12:41.47@0: e8 1c 06 08 b8 1d 06 08 00 00 00 00 01
>>> 00
>>> > 00 00 0c ad a8 7f 5b 00 00 00 b8 98 05 08 b8 98 05 08
>>> >     2020.06.04-15:12:41.47@0: f0 da 6b 77 0c ad a8 7f 28 ad a8 7f 3a
>>> bc
>>> > 6b 77 b8 1c 06 08 0c ad a8 7f 05 00 00 00 a0 10 06 08
>>> >     2020.06.04-15:12:41.47@0:
>>> >     2020.06.04-15:12:41.47@0: code: 0x80521e2
>>> >     2020.06.04-15:12:41.47@0: ff 51 04 83 c4 18 6a 5c 53 e8 a0 9c ff
>>> ff
>>> > 8b 56
>>> >
>>> > This vulnerability was initially found in long-term 6.44.6, and has
>>> been
>>> > fixed in stable 6.47.
>>> >
>>> > 3. Stack exhaustion vulnerability
>>> > The net process suffers from a stack exhaustion vulnerability. By
>>> sending
>>> > a crafted packet to the net process, an authenticated remote user can
>>> > trigger a stack exhaustion vulnerability via recursive function calls.
>>> >
>>> > When testing the proof of concept on an x86 RouterOS VM, this
>>> > vulnerability didn't just crash net process but caused the whole
>>> system to
>>> > reboot.
>>> >
>>> > Against stable 6.46.5, the poc resulted in the following crash dump.
>>> >
>>> >     # cat /rw/logs/backtrace.log
>>> >     2020.06.08-11:19:45.40@0:
>>> >     2020.06.08-11:19:45.40@0:
>>> >     2020.06.08-11:19:45.40@0: /nova/bin/net
>>> >     2020.06.08-11:19:45.40@0: --- signal=11
>>> > --------------------------------------------
>>> >     2020.06.08-11:19:45.40@0:
>>> >     2020.06.08-11:19:45.40@0: eip=0x0809ec65 eflags=0x00010206
>>> >     2020.06.08-11:19:45.40@0: edi=0x7fb0fe4c esi=0x7fb0ff48
>>> > ebp=0x7f311018 esp=0x7f310fe0
>>> >     2020.06.08-11:19:45.40@0: eax=0x00fe0008 ebx=0x7772cae4
>>> > ecx=0x7772cae4 edx=0x08122630
>>> >     2020.06.08-11:19:45.40@0:
>>> >     2020.06.08-11:19:45.40@0: maps:
>>> >     2020.06.08-11:19:45.40@0: 08048000-08121000 r-xp 00000000 00:0c
>>> 1004
>>> >       /nova/bin/net
>>> >     2020.06.08-11:19:45.40@0: 77654000-77689000 r-xp 00000000 00:0c
>>> 964
>>> >      /lib/libuClibc-0.9.33.2.so
>>> >     2020.06.08-11:19:45.40@0: 7768d000-776a7000 r-xp 00000000 00:0c
>>> 960
>>> >      /lib/libgcc_s.so.1
>>> >     2020.06.08-11:19:45.40@0: 776a8000-776b7000 r-xp 00000000 00:0c
>>> 944
>>> >      /lib/libuc++.so
>>> >     2020.06.08-11:19:45.40@0: 776b8000-776c6000 r-xp 00000000 00:0c
>>> 945
>>> >      /lib/libz.so
>>> >     2020.06.08-11:19:45.40@0: 776c7000-776d1000 r-xp 00000000 00:0c
>>> 961
>>> >      /lib/libm-0.9.33.2.so
>>> >     2020.06.08-11:19:45.40@0: 776d3000-776db000 r-xp 00000000 00:0c
>>> 950
>>> >      /lib/libubox.so
>>> >     2020.06.08-11:19:45.40@0: 776dc000-776df000 r-xp 00000000 00:0c
>>> 948
>>> >      /lib/libuxml++.so
>>> >     2020.06.08-11:19:45.40@0: 776e0000-7772c000 r-xp 00000000 00:0c
>>> 946
>>> >      /lib/libumsg.so
>>> >     2020.06.08-11:19:45.40@0: 7772f000-7774c000 r-xp 00000000 00:0c
>>> 947
>>> >      /lib/libucrypto.so
>>> >     2020.06.08-11:19:45.40@0: 77750000-77757000 r-xp 00000000 00:0c
>>> 958
>>> >      /lib/ld-uClibc-0.9.33.2.so
>>> >     2020.06.08-11:19:45.40@0:
>>> >     2020.06.08-11:19:45.40@0: stack: 0x7fb10000 - 0x7f310fe0
>>> >
>>> > This vulnerability was initially found in long-term 6.44.5, and has
>>> been
>>> > fixed in stable 6.47.
>>> >
>>> >
>>> > Solution
>>> > ========
>>> >
>>> > Upgrade to the corresponding latest RouterOS tree version.
>>> >
>>> >
>>> > References
>>> > ==========
>>> >
>>> > [1] https://mikrotik.com/download/changelogs/stable-release-tree
>>> >
>>> >
>>>
>>> _______________________________________________
>>> Sent through the Full Disclosure mailing list
>>> https://nmap.org/mailman/listinfo/fulldisclosure
>>> Web Archives & RSS: http://seclists.org/fulldisclosure/
>>
>>
>>
>> --
>> Gynvael Coldwind
>>
>

-- 
Gynvael Coldwind

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ