Ill-advised research on Linux kernel lands computer scientists in hot water 2

[drawoh]

I am not familiar with the Daily Swig.

Ill-advised research on Linux kernel lands computer scientists in hot water

From Tom's Hardware: Linus Torvalds Responds to Linux Banning University of Minnesota.

--
JHG

 

[IRstuff]

There are professional ways of voicing potential concerns and publishing a report smearing others isnt one of them.

Agree to disagree; I think they tried the "professional" way and got bupkis and condescension, and "be happy, don't worry" because "the system works," and they were forced to prove that it didn't.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[MacGyverS2000]

Was their method unprofessional? Yes.

Was their method necessary to prove the point in such a way that something might actually be done about it (or at least give the issue enough visibility that people who need to care might actually care)? Probably...




Fisch,
Make sure you distinguish between writing secure code and creating a secure system... you can do one without the other, but the end result is the same. I'm sure the coders of SolarWinds were writing secure code (or attempting to, anyway), but they were creating an insecure system by including non-vetted code in their build. It's this latter part the researchers were trying to point out.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[Steve Griffing]

UM was banned by the Linux foundation because they intentionally introduced vulnerabilities into the code repository that feeds all Linux distros, which provide the backbone for most web servers, and a growing number of PCs. This would be like an engineer intentionally creating a safety hazard in a building, or disregarding NFPA, IEC, or OSHA standards when approving a plan, or a manufacturer providing known false tolerances in the documentation of a containment vessels, which puts all the operators at risk. Many people, (myself included), search for and prove the vulnerabilities of systems, in order to show the system owner the vulnerability, and mitigate the risk. Finding and exploiting an existing risk, while providing mitigations so that the client isn't negatively impacted is ethical. However, sending out a broken or intentionally vulnerable system, and lying about its security, is always wrong.

Steve Griffing
PE(CSE), CISSP-ISSEP, PMP, PSP, CEH
ICS Security Engineering
Griffing Technology LLC

 

[Fischstabchen]

Steve,

It is nothing like that because it never went out into the wild. If the Linux team was confident that they would catch all security problems, they should have had a third party do exactly what the people at U of MN did to validate their processes and run mock drills. I have worked in compliance and anything that isn't checked or verified isn't happening 100% of the time and is destined to fail badly.

I worked for a group in a company that provided compliance oversight to a bunch of facilities. One of our tasks was to provide instruction to all the plant engineers and operators as to how to stay in compliance. Part of that was in person and part of that was through web tutorials. I had a hunch that not everyone was doing the mandated tutorials so I went through all the records and found out that a few plant engineers and operators skipped all the mandated online training. This was a NERC violation because one of our compliance violation mitigations put this training in motion. I sent out an email listing out everyone that still had open tutorials that needed to be completed. Some People got pretty mad at me for doing that but the reality is that unless someone cares about the greater good, no problem ever is exposed. The reality is that even if people are made at these two researchers, literally billions of dollars will likely be saved if it leads to improved processes for validating software packages.

 

[Steve Griffing]

I've spent my entire career in a risk adverse and image sensitive bureaucracy, and have often seen the lightbulb come on when someone sees the gaping hole that their career is jeopardized by. I routinely advocate and participate in red teaming and penetration testing endeavors. However, I always get non-reputable proof of proper authority, before any action. I learned the hard way that there are hard limits on "ask forgiveness, not permission". Ethics and personal integrity always trumps organizational regulations, however, the conflict between the two is seldom present, and these researchers, and their University didn't do the due diligence to ensure that the appropriate authorities and permissions were negotiated and established prior to the beginning of their work.

Steve Griffing
PE(CSE), CISSP-ISSEP, PMP, PSP, CEH
ICS Security Engineering
Griffing Technology LLC

 

[LionelHutz]

Sometimes, the only way to know the validity of a error catching system is by testing it. It's not much of a test if the people/processes being tested are told the test has just been introduced.

Sometimes, you can only prove a system doesn't work by introducing a flaw and showing how it doesn't get caught.

The people reviewing who should have caught the bad code where caught out missing it and are butt hurt. Retaliation is the real reason for the university being banned.

Anyone who clams Linux has so much peer review that bad code can't be introduced is simply lying to themselves.

 

[MacGyverS2000]

It's not much of a test if the people/processes being tested are told the test has just been introduced.

Unless you're testing a phishing system. I'm always amazed at how many people fall for phishing emails a mere hour after mass anti-phishing training happens and everyone is told (ahead of time) a test phish email will go out. SMDH...

Dan - Owner

http://www.Hi-TecDesigns.com

 

[Steve Griffing]

The guys who sign off on penetration tests are the C-Suite stakeholders and responsible PEs who actually own the risk, not the helpdesk leads or watch supervisors, and it's held close on a tight individualized 'need-to-know' basis. The contracting and coordination of a penetration test are kept independent of the normal operational chains of command, so that those on the watch floor are not informed. That way, the get-out-of-jail free card is legitimate, but the test is also legitimate.

Steve Griffing
PE(CSE), CISSP-ISSEP, PMP, PSP, CEH
ICS Security Engineering
Griffing Technology LLC