How Can Any Company Ever Trust Microsoft Again?

Skype, bought by Microsoft in May 2011. In 2012, there were discussions about whether Microsoft had changed Skype's architecture in order to make snooping easier (the company even had a patent on the idea.) The recent leaks seems to confirm that those fears were well founded, as Slate points out:

There were many striking details in the Washington Post’s scoop about PRISM and its capabilities, but one part in particular stood out to me. The Post, citing a top-secret NSA PowerPoint slide, wrote that the agency has a specific “User’s Guide for PRISM Skype Collection” that outlines how it can eavesdrop on Skype “when one end of the call is a conventional telephone and for any combination of 'audio, video, chat, and file transfers' when Skype users connect by computer alone.”

But even that pales into insignificance compared to the latest information obtained by Bloomberg:

Microsoft Corp., the world’s largest software company, provides intelligence agencies with information about bugs in its popular software before it publicly releases a fix, according to two people familiar with the process. That information can be used to protect government computers and to access the computers of terrorists or military foes.

Redmond, Washington-based Microsoft (MSFT) and other software or Internet security companies have been aware that this type of early alert allowed the U.S. to exploit vulnerabilities in software sold to foreign governments, according to two U.S. officials. Microsoft doesn’t ask and can’t be told how the government uses such tip-offs, said the officials, who asked not to be identified because the matter is confidential.

Frank Shaw, a spokesman for Microsoft, said those releases occur in cooperation with multiple agencies and are designed to give government “an early start” on risk assessment and mitigation.

So let's think about that for a moment.

Companies and governments buy Microsoft's software, depending on the company to create programs that are secure and safe. No software is completely bug-free, and serious flaws are frequently found in Microsoft's code (and in open source, too, of course.) So the issue is not about whether software has flaws - every non-trivial piece of code does - but how the people who produce that code respond to them.

What companies and governments want is for those flaws to be fixed as soon as possible, so that they can't be exploited by criminals to wreak damage on their systems. And yet we now learn that one of the first things that Microsoft does is to send information about those vulnerabilities to "multiple agencies" - presumably that includes the NSA and CIA. Moreover, we also know that "this type of early alert allowed the U.S. to exploit vulnerabilities in software sold to foreign governments".
http://blogs.computerworlduk.com/open-enterprise/2013/06/how-can-any-co…

( anr | 2013. 06. 21., p – 16:48 )

That means it's highly likely that vulnerabilities in Microsoft products are routinely being used to break into foreign governments and companies for the purpose of various kinds of espionage. So every time a company installs a new patch from Microsoft to fix major flaws, it's worth bearing in mind that someone may have just used that vulnerability for nefarious purposes.

...
Suppose that the US spies used flaws in Microsoft's software to break into a corporate system and to spy on third parties. I wonder whether companies might find themselves accused of all sorts of crimes about which they know nothing, and face prosecution as a result. Proving innocence here would be difficult, since it would be true that the company's systems were used for spying.

At the very least, that risk is yet another good reason never to use Microsoft's software, along with all the others that I have been writing about here for years. Not just that open source is generally cheaper (especially once you take into account the cost of lock-in that Microsoft software brings with it), better written, faster, more reliable and more secure, but that above all, free software respects its users, placing them firmly in control.

It thus frees you from concerns that the company supplying a program will allow others secretly to turn the software you paid good money for against you to your detriment. After all, most of the bug-fixing in open source is done by coders that have little love for top-down authority, so the likelihood that they will be willing to hand over vulnerabilities to the NSA on a regular basis, as Microsoft does, must be vanishingly small.

--
Live free, or I f'ing kill you.

( vargad | 2013. 06. 21., p – 20:06 )

Ez mind igaz, ugyanakkor igen nehéz védekezni, az NSA vagy _bármelyik_ másik ország titkosszolgálata nyugodtan foglalkoztathat pár embert akik biztonsági hibákat helyeznek el csendben bármelyik zárt vagy open szoftverben.

Ehhh...
How about, így?!
És ez ráadásul nem is volt szándékos (különben nem küldte volna vissza a patchet uptsream merge-re is). Viszont remekül demonstrálja, hogy mennyi ideig tud egy ilyen ordas dolog is rejtve maradni. Hát még ha szándékosan úgy írja meg valaki, hogy ne legyen nyilvánvaló...

Nem magában a szoftver forrásában, hanem az abból lefordított binárisban kell benne lennie a hibának. És nem mindenki fordít magának forrásból... és nem mindenki auditálja azokat a patcheket is, amiket egy disztró maintainer rak rá.
---
Régóta vágyok én, az androidok mezonkincsére már!

Az a balfék (biztos ezt akartad írni, de akkor miért 3 csillagot raktál? :P ) csomagkészítő akaratlanul bebizonyította, hogy a módszere kiválóan működik szándékos esetre is.

DE! A titkosszolgálatnak nem _kell_ szándékosan hibát beinjektálnia, elég, ha tudnak egy egyébként tőlük függetlenül benn levő hibáról.
---
Régóta vágyok én, az androidok mezonkincsére már!

Pedig itt pontosan arrol van szo, amirol beszeltel. Most irrelevans, hogy a hiba szandekos volt-e avagy sem, siman bement egy nagyon komoly biztonsagi hiba ugy, hogy a manyeyeballs eleg sokara szurta ki. A bazar modell csak a lehetoseget adja meg a hiba korai felfedezesere, nem pedig a garanciakat.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

jo, akkor meg egyszer, csak a te kedvedert: az eredeti tezis ugy szolt, hogy egy random titkosszolgalat, barmelyik zart v. nyilt forraskodu projektbe be tud csempeszni egy backdoort, whatever. En erre reagaltam, es ezt vitattam. Az nyilvanvalo, hogy egy kis projektnel, ahol alig par fejleszto / maintainer van, ezt sokkal konnyebb vedeni, mint egy Linux kernel meretu dolognal (de ugye az eredeti tezis ugy szolt, hogy _barmelyikbe_, ami nekem egy kisse fud-szagu volt). A debian bug-nak meg ehhez semmi koze, mert az egy tokeletlen debian csomaggyarto fazon pebkac volt, nem pedig az openssl-be bejuttatott szandekos sec. hole. Gondolom, erted a ketto kozotti kulonbseget.

Diktatorok kezikonyve

Csomagolja valamelyik distro a pilert? Ha nem, akkor bocs, nem szóltam...

Ha viszont igen, akkor ellenőrzöd-e azt is _minden_ disztróban, hogy milyen patcheket raknak rá? Azokat is, amiket nem küldtek el neked merge request-re?

A tapasztalat ugyanis az, hogy általában az upstream fejlesztők leginkább a sokasodó bugreportokból szoktak csak értesülni arról, hogy valamelyik népszerűbb disztróban valami félkegyelmű packager elbarmolt valamit. Felhozhatnám példának a gcc 2.96-ot talán még emlékszel rá...
---
Régóta vágyok én, az androidok mezonkincsére már!

Ha egy diszto csomagolo embere sajat patch-ekkel modositja az x alkalmazast, akkor mar tobbe nem beszelhetunk ugyanarrol az alkalmazasrol. Allaspontom szerint a csomagolo jomunkasemberek max. a configure opciokkal jatszhatnak, de ne modositsanak semmit a forrasban. Csak akkor mondhatja barmelyik disztro, hogy a piler-t szallitja, ha ennek megfelel, ellenkezo esetben ne hivja piler-nek, hanem pl. piler2-nek, stb. De kerdesedre a valasz: nem szallitja egyik disztro sem a piler-t - egyelore.

Diktatorok kezikonyve

Kar, hogy egyaltalan nincs igazad, illetve a sajat igazadat masokra nem fogod tudni rakenyszeriteni. Meg a GPL licenc sem ved meg attol, hogy barmelyik $RANDOM disztro maintainere akarmilyen patchet rakjon az alkalmazasodhoz. A legtobb esetben egyebkent ez kell is, az opensource szoftverek portabilitasa altalaban eleg problemas. Regebben csomagoltam par cuccot Gentoohoz, es meg az olyan nagy nevuek utan is sokat kellett dolgozni, mint a Mozilla. Szoval az, hogy patchelik az alkalmazasokat, az bevett gyakorlat, altalaban szukseges, a patchek pedig a legtobbszor nyilvanosak, csakhat minden szoftverfejleszto ideje es energiaja veges. Egyszeruen keptelenseg minden disztro minden bugfixet soronkent atnezni minden egyes disztrooldali verziovaltasnal.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

meg mindig tartom, hogy ha modositod a munkamat, akkor ne hivd ugyanannak, mint en, mert az mar nem ugyanaz. Lehet, hogy jobb lesz tole, ebben az esetben nyugodtan kuldd be a patch-et, es akkor belepatkoljuk (bar azert vannak fenntartasaim, hogy egy csomagolo ember, mennyire tudja javitani a termeket), de az is lehet, hogy csak ront rajta. Pl. a fentebb hivatkozott debian openssl-re is jobb lett volna az openssl-screwed-by-debian-0.9.x csomagnevvel hivatkozni. Kulonben tenyleg az a furcsa helyzet allhat elo, hogy nekem kell a hatam tartani egy olyan hibaert, ami nem az en saram.

Szoval lehet, hogy a gpl nem ved meg attol, hogy barki szenne patch-eljen egy termeket, de attol igen, hogy a modositott termekre az eredeti neven hivatkozz. Es ez igy van jol.

Diktatorok kezikonyve

meg mindig tartom, hogy ha modositod a munkamat, akkor ne hivd ugyanannak, mint en, mert az mar nem ugyanaz.

Kohm, szoval, ha atirom a konfigokat, az mar nem lesz piler? Uhh.

Hol kezdodik az a pont, ahol meg modositani lehet, es hol vegzodik az, ahol mar nem? Ne feledjuk, itt nem alapveto funkcionalitasvaltasrol beszelgetunk (tehat nem egy levelarchivalot akarunk atkepezni interaktiv szakacskonyvve), hanem valamilyen javitasrol, ami az adott kornyezetben relevansnak szamit.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Ha kizárólag te fejleszted, akkor te biztosan tudhatod, hogy nincs benne. Nehéz elképzelni, hogy valaki csak olyan szoftvereket használjon amit kizárólag ő írt.

Ki tudja egy szép napon kapsz te is egy tetszetős patchet amin semmi különös nem látszik, és mergeled...

Gondolom hallottál már erről az aranyos versenyről: http://en.wikipedia.org/wiki/Underhanded_C_Contest

en arrol a versenyrol hallottam, amelyiknek az a szlogenje, hogy 300 sorban mar egy teherautot el lehet rejteni. A kapott patch sanszos scenario, de a wiki oldal szerint "hiba" van benne: "and looks like an honest mistake." Innentol fogva mar csak arrol van szo, hogy eleg rigorozus-e a patch atnezese. En az "honest" hibakat sem szeretem, es kapott patch-eket nem a patch-csel merge-olom, hanem soronkent a kicsi kezemmel illesztem be a megfelelo helyre, es kozben alaposan atnezem. De persze ez sem 100% garancia.

Diktatorok kezikonyve

No jó, akadnak olyan programok amikbe nehéz bejuttatni sebezhetőséget, de tekintve, hogy egy átlag linux desktop kb 1000 csomagból áll, de a szerver se megy 300 alá, a sebezhetőség bárhol lehet...
Windowson semmivel sem jobb a helyzet, igaz az egész rendszert a Microsoft fejleszti így nincs sok apró különálló csomag, de a helyzet azonos: van egy tonnányi komponens amit különböző csapatok raktak össze a Micrsoftnál és nem tudhatja senki hol volt megfizetve valaki, de még a forráskódot sem nézegeti annyi ember. Ahogy egy másik threadben olvashattuk itt a hupon, a review nem igazán működik a csapatokon belül/között, a programok esetenként csak úgy vannak összetákolva, hogy éppen működjenek. Ha valaki kellően ügyes/szerencsés több komponensebe is juttathat sebezhetőséget ha valamelyik lusta fejlesztő lemásolja a kódját.

Az altalad fejlesztett szoftverek szintjenel ez meg egy mukodo scenario, de nem hiszem, hogy egy linux kernel szintu projektnel, aminel egy kozepes meretu patch olyan parszaz/ezer soros, mar kivitelezheto lenne. Es nem heti ket patchet kapnak, hanem napi otszazat.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Nyiltforrasu kodba a legegyszerubb. Egyszeruen tobb mas mindennel egyutt bekuldi neked, mondjuk ehhez kell valami nagyobb feature, amit egyedul implemental. Ugysem lesz idod/energiad minden sort, amit irt, elolvasni, hogy az mit csinal, es igy szep csendben el lehet akarmit is rejteni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Amíg a piler kis projekt, 1(?) aktív fejlesztővel, addig ez működik. De képzelj el egy nagyobb projektet, 10+ aktív fejlesztővel, amikor százával érkeznek a patchek. Ott egyszerűen nem lehet ezt megcsinálni, a legtöbb amit tehetnek, hogy alaposan átnézik. Ha valaki rendszeresen küld be jó patcheket, egy idő után lankad a figyelem, és az ő patcheit nem is nézik már át olyan alaposan.

( Hevi v | 2013. 06. 22., szo – 01:31 )

Mármint arra gondolsz, hogy "How Can Any Company Ever Trust Google Again"?