"Céllal hoztak létre kernel bugokat ..."

Címkék

Egy érdekes szál kezd kibontakozni az LKML-en. Bugok kerültek a mainline Linux kernelbe. Greg Kroah-Hartman (és mások) szerint nem kezdők ügyetlenkedéséről, hanem szándékos, céllal létrehozott bugokról van szó ...

On Wed, Apr 21, 2021 at 02:56:27AM -0500, Aditya Pakki wrote:
> Greg,
> 
> I respectfully ask you to cease and desist from making wild accusations
> that are bordering on slander.
> 
> These patches were sent as part of a new static analyzer that I wrote and
> it's sensitivity is obviously not great. I sent patches on the hopes to get
> feedback. We are not experts in the linux kernel and repeatedly making
> these statements is disgusting to hear.
> 
> Obviously, it is a wrong step but your preconceived biases are so strong
> that you make allegations without merit nor give us any benefit of doubt.
> 
> I will not be sending any more patches due to the attitude that is not only
> unwelcome but also intimidating to newbies and non experts.

You, and your group, have publicly admitted to sending known-buggy
patches to see how the kernel community would react to them, and
published a paper based on that work.

Now you submit a new series of obviously-incorrect patches again, so
what am I supposed to think of such a thing?

They obviously were _NOT_ created by a static analysis tool that is of
any intelligence, as they all are the result of totally different
patterns, and all of which are obviously not even fixing anything at
all.  So what am I supposed to think here, other than that you and your
group are continuing to experiment on the kernel community developers by
sending such nonsense patches?

When submitting patches created by a tool, everyone who does so submits
them with wording like "found by tool XXX, we are not sure if this is
correct or not, please advise." which is NOT what you did here at all.
You were not asking for help, you were claiming that these were
legitimate fixes, which you KNEW to be incorrect.

A few minutes with anyone with the semblance of knowledge of C can see
that your submissions do NOT do anything at all, so to think that a tool
created them, and then that you thought they were a valid "fix" is
totally negligent on your part, not ours.  You are the one at fault, it
is not our job to be the test subjects of a tool you create.

Our community welcomes developers who wish to help and enhance Linux.
That is NOT what you are attempting to do here, so please do not try to
frame it that way.

Our community does not appreciate being experimented on, and being
"tested" by submitting known patches that are either do nothing on
purpose, or introduce bugs on purpose.  If you wish to do work like
this, I suggest you find a different community to run your experiments
on, you are not welcome here.

Because of this, I will now have to ban all future contributions from
your University and rip out your previous contributions, as they were
obviously submitted in bad-faith with the intent to cause problems.

*plonk*

greg k-h

[...]

On Tue, Apr 20, 2021 at 01:10:08PM -0400, J. Bruce Fields wrote:
> On Tue, Apr 20, 2021 at 09:15:23AM +0200, Greg KH wrote:
> > If you look at the code, this is impossible to have happen.
> > 
> > Please stop submitting known-invalid patches.  Your professor is playing
> > around with the review process in order to achieve a paper in some
> > strange and bizarre way.
> > 
> > This is not ok, it is wasting our time, and we will have to report this,
> > AGAIN, to your university...
> 
> What's the story here?

Those commits are part of the following research:
https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf

They introduce kernel bugs on purpose. Yesterday, I took a look on 4
accepted patches from Aditya and 3 of them added various severity security
"holes".

Thanks

A szál itt kezdődik.

Hozzászólások

Apa kezdődik .... :D 

“Luck Is What Happens When Preparation Meets Opportunity" - Seneca

Nem, ez nem kezdődik, hanem itt végződik, nagyon helyesen. Hála istennek a kernelt felügyeli a két nagy öreg, Torvalds és Hartmann, és az ilyen szutykokat szépen ki is szűrik, pont ez a feladatuk is a projektben, hogy ne legyen felhígulás, meg ügyeskedés, és ebben szépen teljesítenek. Nincs itt semmi látnivaló, megfelelően végzik a munkájukat. Időben fel lett ismerve a probléma, és megfelelően hárítva lett.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Erre szokták mondani, hogy nincs mivel játszani, játssz azzal, amivel egyidős vagy.

trey @ gépház

Ez az egyetemi fedősztori egész jópofa. Akár még értelme is lenne ilyen kutatásnak, simán eladható, hogy "jó cél érdekében" teszik, amit tesznek. Vizsgálják a manyeyeball hatékonyságát tudományos módszerekkel.

Aztán ha 1-2 bug átcsúszik a szűrőn mégis, akkor lehet némi mellékest is keresni 0-day sebezhetőségek árusításával a feketepiacon a kutatást végzőknek. Még hogy az oktatási szektorban nem lehet meggazdagodni. :^)

Kontrollált körülmények közt, afféle etikus hackelés szerűen - előre leadott patchek Torvaldsnál és/vagy a főbb karbantartóknál, őket beavatva - tesztelni a rendszer éberségét, nem tartanám feltétlen ördögtől valónak.

Jó hírét keltették a Minnesota Egyetemnek, ha pedig igaz, hogy az egyetemet banra teszik patchbeküldés szempontból, akkor kárt is okoztak.

trey @ gépház

Az ethical considerations resz tetszik a paper-ben...

Egyreszt hogy a f**ba gondoltak, hogy mukodni fog, es nem fogjak oket az elso 1-2 sikeres probalkozas, majd utana rogton felfedes utan elkuldeni a francba?
Masreszt meg a level-threadekbol vegigkovetheto, hogy mennyire szigoruan tartottak be a sajat szabalyaikat (pl hogy lehet most 4 olyan commit, amit GKH-ek visszamenoleg revertalnak, ha minden "accepted" utan azonnal felfedtek az adott maintainernek, hogy csak kiserlet volt?!).

Régóta vágyok én, az androidok mezonkincsére már!

Lehet az a 4 commit nem tartalmazott hibát, beküldtek pár legit javítást is "álcából".

Mindenesetre fura az egész sztori. Elsőre azt mondanám, hogy nem vet jó fényt a kernel közösségre sem, de jobban belegondolva elég hamar meg lett fogva a turpisság és a legjobb megoldás született rá. Ha nem vágnák ki átnézetlenül visszamenőleg is az összes commitjukat a kernelből, az jelzés lenne más támadóknak, hogy ha le is lepleződnek, az elég jól elrejtett bugok benn maradhatnak a kernelben.

Egyebkent most olvasom, hogy GKH 68+ commit-rol beszel, aminek a tobbsegehez masok mar hozzanyultak es revertaltak, felulirtak, vagy egyeb modon kijavitottak. Ugyhogy ugy tunik a szuron tenylegesen keves jutott at valtozatlan formaban. De nyilvan innentol kezdve mindegyiket gyanusnak kell tekinteni, azt is amelyik latszolag rendben van.

De azt is tobben emlitik, hogy lesz meg errol szo a maintainers summit-on, es sajnalatos fordulopont, hogy innentol az ismeretlen szerzoktol szarmazo commit-ot alapbol rosszindulatunak kell kezelni.

Régóta vágyok én, az androidok mezonkincsére már!

Elég csúnya munka lesz mindet szépen kipucolni, a javítást-javított-patchet átnézni hogy vajon maradt-e benne rosszindulatú módosítás...

Nagy g@ciség volt beletojni a palacsintatésztába a kedves "kutatók" részéről.
Kb olyan mintha Boing 737 MAX terveibe valaki belepiszkálna, hogy "észreveszik-e a parasztok"... és ezzel akár konkrétan életeket veszélyeztet.
Az örök ban ezeknek a felelőtlen tetveknek sem lenne túlzás.

Aki nem szeret a szarban túrni, ne menjen kernelőrnek. Aki nem kívánja vállalni azt a felelősséget, hogy az általa őrzött kernel kritikus rendszereket üzemeltet, ne menjen kernelőrnek. Akinek nem tetszik, hogy észre kell vennie, ha egy titkosszolgálat képzett, tapasztalt "kernelfejlesztője" bugot csempész a kódba, ne menjen kernelőrnek. Akit letaglózna, hogy egy "rossz szándékú" entitás más árnyékába bújva vagy mást megszemélyesítve a saját "rossz szándékát" szolgáló "álcázott" patchet küldhet be, az ne menjen kernelőrnek.

:)

Azzal egyetértek, hogy bannolni kell őket. Pár napja meg egyenes azon az állásponton voltam, hogy örökre. De azóta olvasgattam más fórumokon is a témában, és ott valaki nagyon helyes rávilágított, hogy az örök ban az cancel culture húzás lenne, és ebben igaza van. De átmeneti ban szerintem mindenképp kell, mert ha az nincs, akkor nem volt következménye, és az arra sarkall majd jövőben ezzel próbálkozókat is, hogy érdemes ezt kipróbálni, mert max. lebukik, de akkor meg sűrű bocsánatkérés elég lesz. Nem, nem lesz, kapjanak csak pár hónapra bant. Ez egyszerűen így igazságos mindenkivel szemben, nem haragudás kérdése.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Innentől? :szemüveg törlős szmájli:

Ugyan nem követem közelről, de nekem úgy tűnt, hogy az új arcokat azért mentorálják, meg signoffolják a patcheket, meg ilyesmik.... Ha nem is direkt rosszindulatot, de legalább súlyos inkompetenciát nem feltétlen megfelelő helyismeretet feltételezve.

Igazabol nem en mondom, hanem az egyik kernel-fejleszto. Erre a konkret levelre utaltam:

https://lkml.org/lkml/2021/4/21/873

It might be worthwhile to have a discussion at the upcoming maintainers
summit on how to handle contributions from untrusted sources in the
future, and how to identify trusted contributors. Quite obviously the
paradigm has finally changed from "assume the contribution is
well-intended" to "assume the contribution is malicious". I guess that
was prone to happen, but it is sad to experience it anyway.

For my part, congratulations (in a negative sense): You made me much less
inclined to accept minor bug fixes from people I don't know in the future.

Amiket mondasz az termeszetesen igaz, de alapvetoen joindulatot tetelez fel.

En tovabbmegyek, a reviewerek eddig is fel voltak keszulve bizonyos merteku rosszindulatra. Random "trash-commitokrol" mar egy ideje lehetett olvasni hireket. Leginkabb 2 prominens azsiai orszagbol erkeztek, es a motivacio tobbnyire az volt, hogy az illeto neve valahogy bekeruljon a CREDITS-be, es utana tudjon a CV-jeben villogni a referenciaval, hogy "o bizony Linux-fejleszto". Nagyreszt fogalmatlan random belebarmolasok, kommentek szuksegtelen atirasa, formazas megvaltoztatasa volt jellemzo. Ezeket azert a reviewerek eleg jol ki tudjak szurni, meg ha feleslegesen faraszto melo is.

Az a "szonyegbombazasi" technika amit most csinaltak, tudtommal eddig pelda nelkuli volt. Sok subsystem-et vegigszortak pull requestekkel, hogy lehetoleg ne egy maintainernel landoljanak a gyanus commitok, igy ne legyen annyira feltuno, hogy ugyanaz az illeto irja oket. Raadasul ezek egy resze sunyi modositas volt, leginkabb versenyhelyzet-jellegu hibakat hoztak be. Komolyabb hozzaertest es tobb gondolkodast igenyelt rajonni, hogy egy nemletezo hibat "javit", mikozben valojaban kart okoz. A mostani mail threadben olvastam olyat, ahol a kernelfejlesztok is elbizonytalanodtak, hogy nem lehetseges-e az a hiba, amit "javitani" probalt.

Ami nagyon rossz, hogy ezekbol valamennyi eredetileg atcsuszott, most otletet adott nagyobb koltsegvetesu szervezeteknek, hogy ez a tamadasi modszer celravezeto.

Régóta vágyok én, az androidok mezonkincsére már!

Láttam, és egyet értünk, hogy szerintem is csináltak eddig ilyet, de igazságod vagyon, lehet hogy az, hogy valami faszom egy amcsi egyetemről ezzel játszik viszonylag kifinomultan, fog csinálni egy sokkal tudatosabb hozzáállást.

[troll] meg úgyis jön a rust, minden jó lesz [/troll]

Szerkesztve: 2021. 04. 21., sze – 15:19
[PATCH 000/190] Revertion of all of the umn.edu commits

[...]

I have been meaning to do this for a while, but recent events have
finally forced me to do so.

Commits from @umn.edu addresses have been found to be submitted in "bad
faith" to try to test the kernel community's ability to review "known
malicious" changes.

[...]

Because of this, all submissions from this group must be reverted from
the kernel tree ...

https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfound…

trey @ gépház

Bocsanatkeres... igazad van, vegulis annak kellett volna jonnie, de ez inkabb egy (bena) magyarazkodasnak tunik.

> I am so sorry for the concerns. I fully understand why the community is
> angry. Please allow me to have a very quick response, as Jiri requested. We
> will provide a detailed explanation later.

A szokasos "sajnalom az onok aggodalmat" fake-apology formula...

> These are two different projects. The one published at IEEE S&P 2021 has
> completely finished in November 2020. My student Aditya is working on a new
> project that is to find bugs introduced by bad patches. Please do not link
> these two projects together.  I am sorry that his new patches are not
> correct either. He did not intentionally make the mistake.

Ha ez igaz, akkor ugy tunik, itt Aditya az, aki nem ertette meg, hogy mit is jelent, hogy "do not link these two projects together".

Vagy ez a new project ugy mukodik, hogy eloszor introduce-olunk bugot, aztan meg jol "megtalaljuk"? :)

Régóta vágyok én, az androidok mezonkincsére már!

Egyébként az a "céllal" az nem "szándékosan" akar lenni? Tudunk olyan példát, amikor az előbbi az utóbbi helyett használatos? (Pl. "véletlenül meglökte" vs "céllal szándékosan meglökte". Ez esetben nem működik, legalábbis szerintem.) <nyelfnátzi />

Komoly... A timestampeket nézve 5 perc alatt visszavont pár tucat commitot. Vajon mennyi ideig tarthatott ezt korrektebben átnéznie, hogy nem lesz-e gond ezekből a revertekből, mert vmi épp már referált rá? Vagy vajon mind ránézésre annyira "triviális" (szinte semmiségnek tűnik), mint ami 1-2-be belenézve látszódik és ilyen f*szságokra miért is referálna bármilyen kód?

Mindenesetre megértem gregkh felháborodását. A paper kiadása előtt minimum jelezni kellett volna ezt, és nem ilyen számú "próbálkozást" megejteni, meg ilyen mértékben teleszemetelni prod kódot még "nemes" cél érdekében sem. Értem én, hogy figyelemfelhívás, de azért mindennek van határa...

Ha en csinalnek ilyet a munkahelyemen, megkoszonnek, hogy eredmenyesen ramutattam a hibakra, majd kibasznanak mert nem tisztessegesen mutattam ra a hibakra. Es orulhetnek ha az utcaban nem a civakodo rendorok es feketeruhasok varnanak, hogy szandekos karokozas miatt, vagy egyenesen terrorcselekmenyert vigyenek-e be. En ezt igy latom.

Mielott sec tesztelni kezdek, beavatom a fonokomet, meg azt aki felelos a rendszerert. Ha enelkul teszem, az tamadas.

Én értem, hogy ez szerinted miért baj etikailag, viszont nehezen hinném, hogy jogilag is baj lenne. Az ilyen nyílt forrású projektekhez jellemzően a világon semmi garancia nincs. Ha valaki a Linux hibája miatt pórul jár, csak magára vethet. Kb. mindegy, hogy egy adott hiba véletlen vagy direkt került bele (és utóbbit amúgy se nagyon lehet bizonyítani, és az a paper is pont az ellenkezőjét állítja).

Kíváncsiságból utánanéztem. Magyarországon ez terror jellegű bűncselekménynek számít, ha tényként fogadjuk el, hogy az internetre kötött eszközök milliárdjain Linux kernel fut és így a kommunikációs hálózat részének tekintjük.

Szerintem az internet egy olyan alap infrastruktúra ma már, mint az elektromos hálózat. Nem tudnám elképzelni, hogy a jogrend ezt nem védi.

A BTK-ból (Büntető Törvénykönyv) másoltam be ide részeket:

 

318/A. § (2) Az (1) bekezdés vonatkozásában terror jellegű bűncselekmény:

j) a közérdekű üzem működésének megzavarása

 

459. § (1) 21. közérdekű üzem:

c) az elektronikus hírközlő hálózat

 

Közérdekű üzem működésének megzavarása

323. § (1) Aki közérdekű üzem működését jelentős mértékben megzavarja, bűntett miatt egy évtől öt évig terjedő szabadságvesztéssel büntetendő.

(2) A büntetés két évtől nyolc évig terjedő szabadságvesztés, ha a bűncselekményt

a) csoportosan,

b) bűnszövetségben vagy

c) különösen nagy kárt okozva

követik el.

(3) A büntetés öt évtől tíz évig terjedő szabadságvesztés, ha a bűncselekményt

a) fegyveresen,

b) felfegyverkezve vagy

c) különösen jelentős kárt okozva

követik el.

(4) Aki a közérdekű üzem működésének megzavarására irányuló előkészületet követ el, vétség miatt két évig terjedő szabadságvesztéssel büntetendő.

(5) Aki a bűncselekményt gondatlanságból követi el, vétség miatt három évig, különösen nagy vagy ezt meghaladó kár okozása esetén egy évtől öt évig terjedő szabadságvesztéssel büntetendő.

Az törvényszöveg, copy + paste, nem a véleményem. LOL

Én is programozó vagyok és én is vétek hibákat. Viszont nem csinálok olyat, hogy szándékosan javításnak álcázott hibákat teszek mások kódjába.

Sok nyílt forrású cuccot használok, van, amihez én is hozzájárulok időnként, sokszor pont órákig tartó hibakeresés eredményeként.

Engem konkrétan zavar, hogy mások meg pont az ellenkező irányban akcióznak büntetlenül. Bocs, én ezen nem tudok röhögni.

Az utolsó bekezdés alapján azt is börtönbe kell (lehet) zárni (akár három évre is), akinek a kódja nem hibamentes ("gondatlanság"). Nagyon merészek ezek a kernelfejlesztők! Sőt, a webszerverek programozói is túl vakmerőek, hiszen ott is elég egy-két bug, aztán irány a dutyi.

Ezt rosszul értelmezed. Egyrészt a 318 és a 318/A § a terrorcselekmény finanszírozásáról szól, nem az elkövetéséről. A közérdekű üzem működésének megvalósulása önmagában nem terrorcselekmény (finanszírozása), a lista amiből idéztél arról szól, hogy az egyébként a 318 § (1) es pontjában meghatározottat teszi (gyak terroristát pénzel / segít), akkor mik azok a cselekmények, amiket a másiknak csinálni kell.

Van egy ugyanilyen lista a 314 §-ban, ami a konkrét terrorcselekményről szól. Nem tudom, hogy miért nem volt elég egy helyen (lehet, hogy nem teljesen van fedésben egyébként). Viszont itt sem lesz önmagától terrorcselekmény. Hogy az mi, az a 314 § (1)-ben van:

Aki abból a célból, hogy

a) állami szervet, más államot vagy nemzetközi szervezetet arra kényszerítsen, hogy valamit tegyen, ne tegyen vagy eltűrjön,

b) a lakosságot megfélemlítse,

c) más állam alkotmányos, társadalmi vagy gazdasági rendjét megváltoztassa vagy megzavarja, illetve nemzetközi szervezet működését megzavarja,

a (4) bekezdésben meghatározott személy elleni erőszakos, közveszélyt okozó vagy fegyverrel kapcsolatos bűncselekményt követ el,

A 4. bekezdésben van a lista, hogy mik ezek a bűncselekmények, azon van rajta a közüzem megzavarása. Vagyis ha valaki nem ezért zavar közüzemet, amit fent látható, akkor az nem terrorcselekmény.

 

Ráadásul nem zavar itt ő meg semmit egy szar kommittal, hozzá se nyúl a közüzemhez, azt se tudja, hogy hol használják. Maximum az előkészületet lehet egy ilyenre ráhúzni: 

"(4) Aki a közérdekű üzem működésének megzavarására irányuló előkészületet követ el", de ezt is csak akkor, ha bizonyítható, hogy azért tolta be a szar patchet, hogy majd azon keresztül bántsa később a közüzemet.

Hirtelen sok önkéntes fejlesztő is beijedne.

Valószínűleg ez a cél hosszútávon. Maradnak a multik által foglalkoztatott bedolgozók, akik mögött ott áll a jogi osztály és nincs félnivalójuk. Végül a userspace után a kernelspace is korporatokrata kezekbe kerül. Linust meg majd félreállítják valami cancel culture hadjárattal, mint Richard Stallmant. Megfelelő számú és arroganciájú SJW be tudja bizonyítani, hogy az NVIDIÁ-nak való bemutatása is szexista és a nőket kirekesztő, szexuális erőszakra buzdító megnyilvánulás volt.

Szerkesztve: 2021. 04. 21., sze – 20:25

Mindig is ugy volt, hogy a ciganyok munkajat duplan at kell nezni.