|
The fun thing is that in addition to whatever the university concludes about what went wrong, they're probably going to have to formally contact the kernel maintainers to ask what they can do to make things right.
|
#
?
Apr 21, 2021 23:15
|
|
|
|
| # ? Apr 27, 2024 03:16 |
|
|
quote:The completely unrelated 
|
|
#
?
Apr 21, 2021 23:26
|
|
|
https://twitter.com/mjg59/status/1384930082301620225?s=21
|
|
#
?
Apr 21, 2021 23:32
|
|
|
While they're at it be sure to ask whether bricking the devices would be a crime under the CFAA or whatever.
|
|
#
?
Apr 21, 2021 23:36
|
|
|
lol that the umn study around validation of patches to the kernel ended up being a study around validation of studies approved by the department the study itself feels like something that the sociology dept should have been doing rather than the cs dept anyway, its more about trust among distributed teams than anything to do with cs
|
|
#
?
Apr 21, 2021 23:58
|
|
|
and people in the sociology dept would be significantly more likely to have had any exposure to principles of ethics
|
|
#
?
Apr 22, 2021 00:00
|
|
|
lmao awesome hell of a week for minnesota.
|
|
#
?
Apr 22, 2021 00:03
|
|
|
so i've looked entirely too much into this linux kernel thing; here's the timeline there are some research groups at umn that do legit security research on the linux kernel. they have written a ton of patches fixing apparently legitimate over-releases / leaks, presumably with the help of a static analyzer. many of those patches made it into the stable tree. a few months ago, some of the researchers submitted a handful of small but known-buggy patches. these patches were approved, but the researchers withdrew them immediately, pointing out the bugs. those patches do not seem to have made it into the stable tree. the researchers supposedly did this pseudonymously instead of trading on the university's history of good contributions; i'm not going to bother tracking that down to conform. the researchers wrote a pretty shoddy paper calling out the kernel reviewers, full of wisdom like recommending that codes of conduct forbid intentionally introducing bugs. i assume the reviewers did not appreciate this at all. more recently, one of the researchers submitted a patch under their real name which "fixes" a non-bug: it adds a null-check on something that anyone who understands the code would understand is not null. so it's a worthless patch, but not a buggy one, or really in any way dangerous. a couple of maintainers have decided that this worthless patch is of a kind with the previous buggy patches, that it demonstrates continued bad faith. those researchers are now reverting all the previous bug fixes from the stable tree and insisting they be re-reviewed to me it seems obvious that (1) this particular group of researchers has some pretty low standards and (2) the kernel maintainers are mostly interested in taking revenge on the university for embarrassing them
|
|
#
?
Apr 22, 2021 00:23
|
|
|
lol. kinda wish they hadnt given them any heads up tho
|
|
#
?
Apr 22, 2021 00:38
|
|
|
ymgve posted:I think the fact that patches with security flaws got accepted is more damning to the kernel team than UMN, IMO it's kinda nice to have a version of the sokal affair where the nerds ate poo poo instead of "ha ha humanities aren't real academia" i guess
|
|
#
?
Apr 22, 2021 00:42
|
|
|
also, it is not at all clear-cut that this study was a violation of any ethical guidelines. psychology studies are basically always held under false pretenses. sociology studies like e.g. submitting resumes under the names "janet" and "keneisha" are regularly approved despite non-voluntary third-party involvement because the presumed impact on those third parties is very low. (a study where researchers actually went through with fake interviews would be much more problematic, but afaik these studies always stop short of that.) the burden of reviewing a minor patch is roughly comparable to the burden of screening a resume or answering a random email, things that are not seen as deep impositions. what the linux kernel maintainers are objecting to is the fact that they got shown up
|
|
#
?
Apr 22, 2021 00:43
|
|
|
rjmccall posted:also, it is not at all clear-cut that this study was a violation of any ethical guidelines. psychology studies are basically always held under false pretenses. sociology studies like e.g. submitting resumes under the names "janet" and "keneisha" are regularly approved despite non-voluntary third-party involvement because the presumed impact on those third parties is very low. (a study where researchers actually went through with fake interviews would be much more problematic, but presumably these studies always stop short of that.) the burden of reviewing a minor patch is roughly comparable to the burden of screening a resume or answering a random email those actions would trigger an irb review even if it was fast. to get an irb exemption in this situation requires that the researchers lied either explicitly or by omission
|
|
#
?
Apr 22, 2021 00:46
|
|
|
Huh, if the researchers immediately withdrew all the patches that were known to be vulnerable as soon as they were approved, that does make it seem a lot less bad than people have been saying.
|
|
#
?
Apr 22, 2021 00:48
|
|
|
mystes posted:Huh, if the researchers immediately withdrew all the patches that were known to be vulnerable as soon as they were approved, that does make it seem a lot less bad than people have been saying. yeah agreed. i understand the "this was a human experiment!" thing but it doesn't really move me much. it's mostly about the risk of introducing a vulnerability into the kernel. like, the human part should've been vetted by the IRB and it's a problem if it wasn't, but i think it would've likely passed muster despite wasting time (cf the resume example)
|
|
#
?
Apr 22, 2021 00:53
|
|
|
hobbesmaster posted:those actions would trigger an irb review even if it was fast. to get an irb exemption in this situation requires that the researchers lied either explicitly or by omission yeah, so the researchers seem to have admitted that they didn't get get prior approval from the irb. that's not a good look even if they reasonably would've gotten that approval. these people do not seem like leading lights. i'm just saying, it's a process failure more than a substantive one; the maintainers are waving the ethics flag because it distracts from their own bad behavior
|
|
#
?
Apr 22, 2021 00:54
|
|
|
it’s still absolutely hilarious that the paper includesquote:D. Feedback of the Linux Community “hi guys, I’m a grad student of a known malicious contributor here with a contribution that appears to do absolutely nothing... WAIT WHY ARE YOU BANNING ME” basically “we have no idea what you’re up to this time or what time bombs you put in a while ago and we really don’t want to deal with it” seems very reasonable despite any potentially real issues
|
|
#
?
Apr 22, 2021 00:59
|
|
|
thinking an experiment involving deception without informed consent wouldn’t require irb is both shameful and completely unsurprising
|
|
#
?
Apr 22, 2021 01:20
|
|
|
Anyone else just get hit by this QNAP ransomware like me? If anyone knows of a fix that would be great https://www.bleepingcomputer.com/news/security/massive-qlocker-ransomware-attack-uses-7zip-to-encrypt-qnap-devices/
|
|
#
?
Apr 22, 2021 01:23
|
|
|
w00tmonger posted:Anyone else just get hit by this QNAP ransomware like me? If anyone knows of a fix that would be great
|
|
#
?
Apr 22, 2021 01:26
|
|
|
Trabisnikof posted:thinking an experiment involving deception without informed consent wouldn’t require irb is both shameful and completely unsurprising I don't care what the interactive ruby interpreter thinks
|
|
#
?
Apr 22, 2021 01:34
|
|
|
lol ive been wondering what irb means this whole time
|
|
#
?
Apr 22, 2021 01:36
|
|
|
incident response/ review board I assume but could be wrong
|
|
#
?
Apr 22, 2021 01:51
|
|
|
the no-preventative-patches thing is reasonable. “this code would be buggy if the code changed!!!” is not a very convincing argument really the kernel should use a programming language that cleans poo poo up when it goes out of scope, but
|
|
#
?
Apr 22, 2021 01:52
|
|
|
The Fool posted:incident response/ review board I assume but could be wrong institutional review board
|
|
#
?
Apr 22, 2021 01:52
|
|
|
https://en.wikipedia.org/wiki/Institutional_review_board
|
|
#
?
Apr 22, 2021 01:53
|
|
|
mystes posted:Out of curiosity is your nas exposed to the internet? I also have a QNAP nas but I'm wondering how you would get infected in the first place. Yeah I'm online with it Digging on forums it sound like this was an exploit that hit the qnapcloud system. Exploit was disclosed to QNAP back in October which doesn't sound good. Disclosure revealed to the public beginning of the month Exploit allowed access through some media services etc, there were a couple of them
|
|
#
?
Apr 22, 2021 02:16
|
|
|
w00tmonger
|
|
#
?
Apr 22, 2021 02:18
|
|
|
rjmccall posted:institutional review board 2/3
|
|
#
?
Apr 22, 2021 02:18
|
|
|
w00tmonger posted:Yeah I'm online with it I realize this isn't at all helpful, but there's no way I would expose something like this running all sort of random services I have no control of directly to the internet, personally (and I'm not using qnapcloud because I absolutely don't trust it).
|
|
#
?
Apr 22, 2021 02:21
|
|
|
mystes posted:It doesn't sound like there's any way to recover the data. I guess the only good thing is it doesn't sound like the data is exfiltrated or anything? I mean 20/20 hindsight obviously. I was mainly using it as a media share but it encrypted a bunch of pictures I was using for an Etsy shop which is a big pain
|
|
#
?
Apr 22, 2021 02:26
|
|
|
the International Rugby Board has unfortunately been renamed, spoiling what could have been a funny joke
|
|
#
?
Apr 22, 2021 02:29
|
|
|
The Fool posted:incident response/ review board I assume but could be wrong it's a perfectly reasonable mistake to make, but i'm still havin a lol
|
|
#
?
Apr 22, 2021 02:33
|
|
|
mystes posted:Out of curiosity is your nas exposed to the internet? I also have a QNAP nas but I'm wondering how you would get infected in the first place. Even without internet exposure there have been exploits for other systems that can be triggered with a single GET request.
|
|
#
?
Apr 22, 2021 02:49
|
|
|
Just to confirm. What should I be nuking in the meantime on this QNAP. Do I just need to kill port forwarding?
|
|
#
?
Apr 22, 2021 02:53
|
|
|
Perplx posted:Even without internet exposure there have been exploits for other systems that can be triggered with a single GET request. w00tmonger posted:Just to confirm. What should I be nuking in the meantime on this QNAP. Do I just need to kill port forwarding? Aside from that you would need to make sure it's not connected to qnap cloud and make sure there aren't ports forwarded to it, yeah. mystes fucked around with this message at 03:03 on Apr 22, 2021 |
|
#
?
Apr 22, 2021 02:57
|
|
|
mystes posted:Sure there's the Samsung TV one but in reality if nobody else has access to your network, unless you're being targeted the risk of having a device exploited by you being tricked into opening a malicious link is completely infinitesimal compared to the risk from having a device exposed to the internet. Sounds like it's a specific exploit where when it has network access they were running batch 7zip commands. Nothing too persistent
|
|
#
?
Apr 22, 2021 03:10
|
|
|
lol if u port forward
|
|
#
?
Apr 22, 2021 03:12
|
|
|
w00tmonger posted:Sounds like it's a specific exploit where when it has network access they were running batch 7zip commands. Nothing too persistent wouldn't this mean the had shell access?
|
|
#
?
Apr 22, 2021 03:15
|
|
|
infernal machines posted:wouldn't this mean the had shell access? Still reading into It, but it sounds like there was a disclosure of some bugs back in October that QNAP were aware of. Dude who disclosed went public recently because QNAP hadn't told the public/fixed it Blog post from the guy https://securingsam.com/new-vulnerabilities-allow-complete-takeover/ E: so yeah, shell access without credentials. VVV: in the process. Should be able to virus scan any files right? Seems like everything over like 20mb(200?) is fine w00tmonger fucked around with this message at 03:57 on Apr 22, 2021 |
|
#
?
Apr 22, 2021 03:52
|
|
|
|
| # ? Apr 27, 2024 03:16 |
|
|
you should probably pull your files and wipe/reflash that thing
|
|
#
?
Apr 22, 2021 03:54
|
|