Overlay típusú támadás kivitelezését megkönnyítő sebezhetőséget javít a szeptemberi Android biztonsági patchcsomag

Android

Android overlay attack

Biztonsági szakemberek arra figyelmeztetnek, hogy az Oreo-nál régebbi Android verziók egy olyan sebezhetőségben szenvednek, amely sokkal egyszerűbbé teszi az ún. overlay típusú támadások kivitelezését. A sebezhetőség a fenti kép értelmezésével egyértelmű: képernyőelemek átfedésével verik át a felhasználót.

A problémát a Google javította a 2017 szeptemberi Android Security Bulletin kiadásával egy időben. Részletek itt.

jaja csak ezzel egy halom object-et csinal a heap-en, jocskan lassubb, nem is szolva a bovithetosegrol, amikor vmit hekkelni kell a kodba. en konkretan sose hasznalok stream-eket, ha valami, akkor a fugue -fele Optional es Iterables a legjobb (abban van fold() is btw).

Az optional meg a stream alma és körte. A többi részben igaz lehet, a stream / lambda valóban nem a mikrooptimalizálás csúcsa, de sokkal szebb a kód.

" nem is szolva a bovithetosegrol, amikor vmit hekkelni kell a kodba"
elaborate pls

--
arch,debian,retropie,osmc,android,windows

izlesek es pofonok, szerintem nem feltetlen szebb.

bovithetoseg alatt azt ertem, hogy a stream egyes lepesei egymastol teljesen fuggetlenek. Ha tehat pl szeretnel infot atadni az egyik map-bol az azt koveto filter -nek, akkor azt csak ugy tudod, ha csinalsz egy uj object-et, es abba pakolsz mindent. Namost ez igy minden lesz, csak szep vagy hatekony nem.

Mig a szokasos sima iteralos megoldassal csak siman definialsz valtozot a cikluson belul, oszt kesz.

Most nagyon felkapott lett a stream valamiert (igy 3-4 evvel a megjelenese utan, haha), de altalaban csak a fejem fogom, amikor a sok onjelolt stream guru nekiall alkotni, aztan irhatom at sima iteraciora kesobb, ami raadasul rovidebb is lesz.

Majd lehet, hogy a spring5 + reactive stream3 jobb lesz.

Az iteráció eleve lineáris feldolgozást jelent. Míg ha a map elkészít egy olyan objektumot, amit a chainben következő filter fel tud használni, akkor párhuzamosan is fel tudod dolgozni az elemeket.

Persze, tök jó dolog az imperatív kódolás, csak amikor párhuzamosítani akarod a dolgokat, mert 1-nél több mag van a gépedben, akkor meg nézel, mint a moziban.

na a stream.parallel() is meger egy miset. marmint a kivetelek, meg hogy mire figyelj, hogy parallel is maradjon. egyszerunek szantak, de a vegen elertek azt a pontot, ahol az rxjava1 kezdodik.

alapvetoen kis workload-okat parallel futtatni nem eri meg egyetlen framework-ben sem. Nagyobbakbol meg van talan mareknyi egy alkalmazasban, ott kulonosebben nem szamit, hogy stream vagy executor vagy observable vagy completablefuture.

"alapvetoen kis workload-okat parallel futtatni nem eri meg egyetlen framework-ben sem. Nagyobbakbol meg van talan mareknyi egy alkalmazasban, ott kulonosebben nem szamit, hogy stream vagy executor vagy observable vagy completablefuture."

Viszont pont az a lényeg, hogy az egész processing chain felépítés független attól, hogy stream() vagy parallelStream() a hívás.
Az, hogy éppen parallel vagy nem parallel streamen kell futtatni ugyanazt a processing chaint, az meg függ a workload méretétől, ami a futás alatt változhat is.
Pont ez a lényege ennek: felépítesz egy processing chaint, és hogy azt éppen milyen bemenő streammel (parallel vagy nem) eteted meg, az majd futásidő alatt dinamikusan is eldönthető, a kód módosítása nélkül.
Baromi nagy rugalmasság ez.

ebben semmi uj sincs, mindezt rxjava observable mar egy evtizeddel ezelott is tudta, sot meg sokkal tobbet is.

es mint az rxjava felhasznaloi, itt is ugyanugy ra fognak jonni, hogy baromi maceras igy dolgozni. debughoz nincs normalis stacktrace, egyaltalan debug mint olyan, iszonyu gazos a sok lambdas ugrabugra miatt. igen, a parallel futas problemajat leegyszerusiti valamelyest (hozzateszem az observable meg az aszinkron futas problemajat is megoldja, nem csak a parhuzamositast), de ahol nincs igazi szukseg parhuzamos futasra, ott egyszeruen csak extra komplexitas.

Ahogy pl. a full aszinkron framework is nagyon allat, papiron, de ha nincs ra szukseg, akkor csak bonyolitja az eleted. sot, jobbat mondok, konkretan noveli a valaszidot a sima blocking IO-hoz kepest.

> debughoz nincs normalis stacktrace, egyaltalan debug mint olyan, iszonyu gazos a sok lambdas ugrabugra miatt.

Ezert kell kitenni kulon fuggvenybe, arra meg mar irhatsz unit testet. Nem is csufitja a hivo kodot, jobban is olvashato egy normalisan elnevezett fuggvenynevvel, sot, ha komolyabb filterezes megy, valszleg azokat is erdemesebb kulon fuggvenybe tenni, es kulon unit-testelni.

sot, jobbat mondok, konkretan noveli a valaszidot a sima blocking IO-hoz kepest.

A válaszidő az nem függ a hívótól, az mindenképp X ms. A különbség a szinkron és aszinkron között annyi, hogy a hívó megvárja az eredményt; vagy nem várja meg, hanem folytatja a futását más feladat végrehajtásával.

Ha a dotty-ra gondoltál, akkor tényleg egyetemi szint jelenleg.
Ha a Scala-ra, akkor viszont el vagy maradva egy pár évvel, mert elég régóta használják a vállalkozások. Egy pár esettanulmányt is elolvashatsz, hogy melyik cég miért kezdte használni.
Viccnek viszont jó volt! :-)

az első felével nem vitatkozom, akár még igazad is lehet.

> hatekonysagokat tekintve tokmindegy, a compiler kioptimakolja a fenti alakra.
ebben viszont kételkedem. A streames mókában egy rahedli object jönne létre tényleg, amit legfeljebb majd a JVM dob el.
A `.forEach` ezzel szemben egy iterátoros for-loop, vagy speciális esetben (ArrayList) még annyi se.

szerk.: najó, most vagy én baszok el valamit, vagy eléggé fura ez: 


# Run complete. Total time: 00:13:27

Benchmark              Mode  Cnt        Score       Error  Units
MyBenchmark.noStream  thrpt  200  1399268.254 ± 22645.847  ops/s
MyBenchmark.stream    thrpt  200  1681940.604 ± 34280.563  ops/s

https://gitlab.com/vilmosnagy/for-each
--
blogom

kód frissítve.
ez egyre inkább érdekes, mert még mindig ez jön ki belőle: 


# Run complete. Total time: 00:13:29

Benchmark              Mode  Cnt        Score      Error  Units
MyBenchmark.noStream  thrpt  200  1229394.134 ± 5963.321  ops/s
MyBenchmark.stream    thrpt  200  1469823.511 ± 7396.206  ops/s

Na, majd holnap, holnapután belemászok, érdekesnek tűnik.
--
blogom

csinaltam egy nativ foreach-et is hozza, meg erdekesebb: 


Result "com.gitlab.vilmosnagy.MyBenchmark.stream":
  2028187.776 ±(99.9%) 39351.353 ops/s [Average]
  (min, avg, max) = (1881462.958, 2028187.776, 2086342.672), stdev = 45317.077
  CI (99.9%): [1988836.422, 2067539.129] (assumes normal distribution)


# Run complete. Total time: 00:02:01

Benchmark              Mode  Cnt        Score       Error  Units
MyBenchmark.foreach   thrpt   20  1507304.321 ± 29227.940  ops/s
MyBenchmark.noStream  thrpt   20  1604092.224 ± 18183.149  ops/s
MyBenchmark.stream    thrpt   20  2028187.776 ± 39351.353  ops/s

Elvileg nem szabadna neki gyorsabbnak lennie...

Nemtom, milyen lock-rol beszel, nincs benne semmilyen lock, csak egy csekk, hogy valtozott-e strukturalisan.

Ami feltunt, az a ArrayList() -en beluli ListIterator.forEachRemaining(), ami ezt teszi: 


                    while (i != size && modCount == expectedModCount) {
                        consumer.accept((E) elementData[offset + (i++)]);
                    }

Szoval egyesevel next() hivogatas, ami persze minden hivasnal csekkel mindent, ez itt batch-ben csinalja ugyanezt.

Roviden: a stream-mel hackeltek maguknak shortcut-okat a meglevo collection-okbe, azert gyorsabb. Ehhez mondjuk sok elemu List kell, probald csak meg a benchmark-ban a listat 100 helyett mondjuk 3-5 elemuve tenni. Vagy te is az ArrayList().listIterator().forEachRemaining() -et hivni, az gyors lesz.

most igy nez ki: 


# Run complete. Total time: 00:02:01

Benchmark              Mode  Cnt        Score       Error  Units
MyBenchmark.foreach   thrpt   20  1944705.567 ± 11251.467  ops/s
MyBenchmark.noStream  thrpt   20  1961385.604 ± 12075.212  ops/s
MyBenchmark.stream    thrpt   20  2286964.231 ± 39944.793  ops/s

ez a kod: 


    @Benchmark
    public void foreach(Blackhole blackhole) {
        List<Integer> list = new ArrayList<>(127);
        OBJECTS.iterator().forEachRemaining(i -> foo(i, list));
        blackhole.consume(list);
    }

https://github.com/agoston/benchmark

eredmeny: 


# Run complete. Total time: 00:02:09

Benchmark               Mode  Cnt        Score        Error  Units
JmhBenchmark.noStream  thrpt   20  4849592.146 ±  67814.798  ops/s
JmhBenchmark.stream    thrpt   20  5493303.912 ± 155966.963  ops/s
JmhBenchmark.zforeach  thrpt   20  5050272.755 ± 108552.013  ops/s

stream meg mindig a leggyorsabb, de multi-threaded esetben mar eltunik a kulonbseg.

> mert egyetlen tenyezo se jut eszembe, amiert a stream gyorsabb lenne.
JVM, és JIT.
Valszeg az összes object ki van dobva onnan, s egészen más fut a processzoron, mint amit elképzelsz.
Nem pont ez a példa, de hasznos olvasmány: https://blog.jooq.org/2016/07/19/the-java-jit-compiler-is-darn-good-in-…

Ha lesz egy kis időm, megpróbálom megnézni a fentit, mi is fut valójában.
--
blogom

Na jo, utolso: 


StreamVsForEachCountBenchmark.forArray             thrpt   20  394817691.863 ± 7977712.622  ops/s
StreamVsForEachCountBenchmark.foreach              thrpt   20   20841775.312 ±  181298.857  ops/s
StreamVsForEachCountBenchmark.foreachArray         thrpt   20  401021284.591 ± 8091448.922  ops/s
StreamVsForEachCountBenchmark.foreachListiterator  thrpt   20   41635174.255 ±  718408.542  ops/s
StreamVsForEachCountBenchmark.noStream             thrpt   20   48749956.074 ±  868837.081  ops/s
StreamVsForEachCountBenchmark.stream               thrpt   20   43258748.145 ±  577222.173  ops/s

Nekem az jott le, hogy ha List-be pakolod, akkor vegulis tokmindegy, hogy stream vagy nem stream. Ha int[] -et hasznalsz, akkor 10-20x gyorsabb lesz a kod. Es, meglepo, de az old-style for a leglassubb.

Valami hasonló fordul ebből: 


 // access flags 0x1002
  private synthetic lambda$stream$1(Ljava/lang/Integer;)V
    ALOAD 0
    ALOAD 1
    INVOKEVIRTUAL java/lang/Integer.intValue ()I
    ALOAD 1
    INVOKEVIRTUAL java/lang/Integer.intValue ()I
    ICONST_1
    IADD
    INVOKESPECIAL com/gitlab/vilmosnagy/MyBenchmark.bar (II)V
    RETURN

Az intValue meg egy sima return.
Ezt nem dobja ki az egészet a francba a JIT? Nem tudja? Miért nem tudja? Máshol miért igen?

--
blogom

( sz332 v | 2017. 09. 11., h – 14:28 )

Azt mondjuk elmondhatná valaki, hogy egyáltaán miért lehet ilyen jogokat adni egy alkalmazásnak?

Van egynéhány olyan alkalmazás, ami jogosan igényelheti. Példa: céges telefonra telepitesz egy exchange-es fiókot, hogy tudj céges levelezni.
A cég jogot követel arra, hogy távolról factory resetbe küldje a telefonodat, ha úgy érzi hogy az accountodat kompromittálták.

--
arch,debian,retropie,osmc,android,windows

( answ | 2017. 09. 11., h – 15:29 )

Miért? Nektek nem a Porn Droid adminisztrálja az eszközeiteket?
Az elosztott tárolás most ingyenes a fappening körben!

( Nyosigomboc v | 2017. 09. 11., h – 15:38 )

A reszletekben leirjak, talan itt is elfert volna.

Van Androidon egy Overlay rendszer, amivel a kepernyore lehet rajzolni kozvetlenul, akar masik alkalmazasok fole (pl. red shiftet meg hasonlokat lehet igy csinalni). Ez kulon jogosultsagot ker ehhez - teljesen jogosan, epp a fenti miatt. A fejlesztok gondoltak az ilyen jellegu tamadasokra, ezert van ez a kulon jogosultsag.

Van egy masik feature, a Toast. Ez mar 2.1-en biztos volt (az elso Androidos telefonom tudta), ennek az volt a lenyege, hogy egy rovid uzenetben tajekoztatni tudja a usert, hogy mi tortent. Par masodpercre megjelenik egy fekete hatteru szoveg (ez a default megjelenese). Ezt tovabbfejlesztettek, mar a fejleszto sajat, testreszabott toast-ot is megjelenithet (gyakrolatilag ugyanazokbol az elemekbol epitkezik, ugyanolyan View-t keszithet, mint az alkalmazasok UI-a). A problema ezzel van. Toast-hoz az Overlay-jel ellentetben nem kell kulon jog.

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

Legjobb tudomásom szerint a Toast tényleg csak pár másodpercre jelenhet meg (van Toast.LENGTH_SHORT ami 2000 ms és Toast.LENGTH_LONG ami 3500 ms - elvileg), de egy alkalmazás akárhányszor megismételheti azt, így gány módon, de lehet "tetszőleges hosszúságút" is alkotni.
__
http://fodi.be

( arpi_esp v | 2017. 09. 11., h – 22:34 )

lol. emlexem meg ugy 20-25 eve, amikor unixokon X-et hasznaltak, es meg nem kellett xhost-al kulon engedelyezni a remote DISPLAY accesst, akkor voltak ilyen overlay trukkok, kirakott tavoli gepre egy nagy atlatszo ablakot ami minden key eventet logolt... regi szep idok, udv ujra :)