Pat has an excellent record of getting things right. I suspect he's testing things before he releases a fix.
I can wait.

2 members found this post helpful.

Yes! You are right!

3 members found this post helpful.

I've built some quick and dirty packages of kernel 3.2.83 since my server still runs 14.0. If anyone else would like a copy let me know and I'll upload them somewhere.

Edit, 32 bit only, sorry.

2 members found this post helpful.

For what it's worth, I can confirm not having any issues with the patched 4.4.27 and 3.10.104 kernels so far, on machines running Slackware 14.1 (32 and 64 bit) and 14.2 (64 bit).

2 members found this post helpful.

i can also confirm that there is no issue running 14.2 with kernel 4.8.4

on Del Latitude 6440

1 members found this post helpful.

I did an update on my 14.2 box, and it updated to kernel 4.4.19. This kernel FAILS my test for the dirty COW exploit.
Slackware 14.1 is currently using the 3.10.103 kernel. This kernel FAILS the test.
I have an AWS instance running the 4.4.23 kernel. This kernel PASSES the test. I mention this in case anyone is using an AWS instance with AMazon's own Linux distro, they patched it a day or so ago.

So forgive me if I'm missing something, but it appears we don't yet have a patched kernel for Slackware 14.1 or 14.2?

I'm not sure I'm concerned enough to do a manual kernel update on any of my boxes, I might just wait for a patched kernel to make into our repository. Is anyone else actually doing anything to their boxes about this at this time?

FYI 60 seconds with duckduckgo (or google) and you can find an example of how to actually test for this exploit. Most of the so-called test programs just inspect your kernel version, but I have a c program that actually exercises the exploit. I'm not sure I should post the link or the program here or not (is it ok for me to post a c program that tests this? The program will very nicely over write a file owned by root with chmod 404). I use this program to actually test my systems, rather than go by kernel version.

2 members found this post helpful.

I updated 14.2 to the 4.4.27 kernel from kernel.org on my personal laptop.. no problems thus far.

1 members found this post helpful.

I've run both Slackware 14.1 and 14.2 with a 4.4.x kernel, never had a problem with the exception of nVidia drivers - their recent versions would not compile and so I'm actually using a driver that is one or two versions back. This is not an issue with my production servers, since I don't install a video driver on them, but I have several workstations with nVidia cards, and I just don't have the time to deal with this <sigh> ...

Forgive me, but in this context, does "PASSES" mean the exploit does not work?

1 members found this post helpful.

My bad for not being more clear

PASS means the exploit does not exist or to be more precise, my test program which uses the exploit to attempt to overwrite a file, fails to overwrite the file. As an example, I tried this on one of my AWS instances which is patched current as of... yesterday I think ... and I am unable to overwrite the test file.

FAIL means it can be exploited. I tried a Slackware 14.1 box and a couple of 14.2 boxes, current patch level, and on both of them I as a non-root user successfully over wrote files that I, a non-root user, have read-only access.

As an example, I just now tested this against httpd (how many of use have apache web server running?) and I, as a non-root user, replaced the contents of httpd with my own file. When I restart my web server, it is going to run my program that will do whatever I want within the realm of permissions normally given to the web server daemon.

There are limitations to what you can do with this. As a non-root user, I normally do not have read access into /root or other user directories, so I can't mess with other user data. I could not, for example, overwrite /etc/shadow with my own version and take root control of your system (because default perms on /etc/shadow is 640 - 'others' don't even have read access). I can, however, overwrite fstab, so what happens when I reboot my system and fstab is wiped? I can rampage through /usr/bin, /usr/lib64, etc., wreaking havoc as I go. I could probably replace executables with my own program. So I'm going to replace some common executable with my own executable, and when the program gets run, my program runs instead.

Do you see what kind of damage you can do, and how easily you can do it? I admittedly don't know how far you can go with this or what the limitations are, but so far I can easily render my system non bootable, or compromise executable files.

The only saving grace here is that one has to have access to the system to start with. There may be other ways to do this, but I'm not a researcher and I really haven't spent that much time with this. On the other hand, it took me less than an hour to figure out how to render a system unbootable and compromise my web server executable. And all of this as a normal non-root user.

Default Slackware installs with today's patch level are vulnerable. All it takes is one brighter than average (and that doesn't take much) kid to test this to see if he can wipe your server. He probably can.

EDIT: DISCLAIMER!!!

Just so that the FBI does not come knocking on my door

- the test program I used was one I found on the Internet that was designed to demonstrate how to see if your system is vulnerable or not. It was a simple c program that I had to compile myself. All it does is overwrite a test file with the contents of your choice. A sucessful over write indicates that the system is vulnerable to this exploit.

- I have tested this ONLY on systems I OWN.

- I have not released or otherwise uploaded or displayed the program or made it available in any form anywhere at all (seriously, you can find it yourself with google in 60 seconds, and if you know anything about c programming and memory and threading, you can write your own fairly quickly).

- I do not advocate or suggest or recommend anyone use this exploit at all for any reason at any time....

3 members found this post helpful.

Did that require local access to the server in question or were you able to create an http request that did the same?

I'm not trying to slam you or anything; I just want to know the parameters around your exploit.

All of my testing required the ability to login to the box, either directly or via ssh. It is equally effective either way. I'm not sure how to do it via an http request, but once you have console access, the box is yours. All you really need is the ability to execute a few commands, like with scp, but you still have to have access to the box.

4 members found this post helpful.

Thank you!

Just to make sure my last build was no fluke, I just updated 14.2 to 4.4.28. No problems whatsoever.

Next time, I want to play around with -j2 to see what that does for build time on my i3. But the process itself couldn't be simpler.

Or just read page 2 of this thread...