jump to navigation

Se il bancomat gira su Windows…

In News, Opinioni il 22/03 @ 12:50 trackback

Windows ATM Cash Machine Bancomat Crash - Pollycoke :)" rel="lightbox[pics4580]" href="/wp-content/uploads/2009/03/20070211.jpg">Windows ATM Cash Machine Bancomat Crash - Pollycoke :)


So cosa state pensando: «tutto qua?». Eh già, non credo di sbagliarmi quando penso che avrete sicuramente già visto centinaia di foto del genere, no? No:

Inserite voi la vostra immagine preferita

Insomma, se ne trova una infinità in rete. Quelle più spettacolari riguardano aeroporti, mega cartelloni informativi o pubblicitari, ecc.

Quella che vedete in apertura l’ho scattata io un paio d’anni fa e non l’ho mai pubblicata appunto perché non ha amaramente niente di eccezionale. La pubblico oggi per rispondere a gondsman, che segnala questa ben più grave storia di bancomat messi in ginocchio da un worm che non si limita a mettere fuori uso un terminale e provocare il solitro disservizio, ma arriverebbe a trafugare dati dei conti bancari!

Non so voi, ma pensare che i nostri ospedali, caserme, scuole e uffici pubblici in genere usano proprio Windows, il sistema operativo virus-friendly, magari in una vecchia versione, magari non aggiornata, magari senza un amministratoer che ne tiene a bada le numerose falle…

Mi mette i brividi

Pagine forse correlate:

Etichette: , , ,

Commenti »

1. ThE_RaY - 22/03 @ 13:02

Anche a me un anno fa ha crashato il bancomat con un errore di windows…il bello poi è che non puoi cliccare sulle finestre di dialogo xD

2. http://olympicmew.wordpress.com/ - 22/03 @ 13:03

Ne ho una collezione immensa anch’io di immagini come quelle. Screensaver in funzione negli orari dei voli in un aeroporto di Montréal, schermate di login in un totem all’ingresso di Castel del Monte… curiosamente all’aeroporto di Fiumicino ho visto invece che al controllo dei documenti usano Solaris… :D

3. Morpheu5 - 22/03 @ 13:04

A me un bancomat si è riavviato davanti agli occhi dopo avermi tenuto in ostaggio la scheda per ben cinque minuti… e solo dopo altri cinque minuti dopo il riavvio ha deciso di espellere il corpo estraneo. Pensa te se me ne fossi andato maledicendo la banca (ché erano tipo le dieci e mezza di sera, mica le undici del mattino).

4. Pappice - 22/03 @ 13:18

ultimamente nelle stazioni trenitalia espone in bella mostra PC bloccati al boot con sistemi unix-like… ma questo penso dipenda solo da Trenitalia! ;-)

5. gondsman - 22/03 @ 13:20

Innanzitutto sono onorato di essere citato in un post!
Secondo me la cosa grave non è il crash, che tutto sommato ci può stare (si poteva anche rompere il tastierino o lo schermo, l’effetto sarebbe stato lo stesso), quanto l’idea che praticamente IL MONDO si affida ad un sistema proprietario che non assicura una adeguata sicurezza. Il worm nel bancomat è un episodio gravissimo, per non parlare del fatto che le banche usano allegramente un sistema di cui non possono conoscere i sorgenti. Dal mio punto di vista un programmatore MS potrebbe pure inserire un pezzo di codice che si ruba coscientemente le password dei bancomat!
L’altra cosa che mi ha dato fastidio è che sui giornali tutti a scrivere che è uscito IE8 (l’articolo su Repubblica era imbarazzante) e nessuno parla, anche come curiosità, di questi fatti, che tutto sommato sono molto più interessanti.

6. lore - 22/03 @ 13:21

Trenitalia fino a poco fa usava postazioni (quelle classiche touch coi pulsantoni delle bandiere per le lingue) che usavano OS/2.
L’ho scoperto vedendo un tecnico che ne riavviava una.

7. cisO.o - 22/03 @ 13:23

a Firenze sugli autobus Ataf, sono presenti 2 schermi che dovrebbero dare informazioni (dico dovrebbero, perchè non sono mai stati aggiornati).
Questi sistemi sono basati su XP Embeeded, e danno errori di windows con una media di 1 su 2. Quindi basta venire a Firenze ;)
Sempre all’università di Firenze, a volte sugli schermi ci sono degli errori… questa volta però di Epiphany.
Questo per dire che a volte ci sono dei geni di “gestori delle reti” che riescono a creare errori anche con linux…

8. Pythagoreion - 22/03 @ 13:40

@4: mmh, a Roma termini i totem delle banchine dell’alta velocità usano windows embedded…. e ogni giorni ce ne è sempre almeno una che non riesce ad effettuare il boot…. rimangono bloccate giornate intere sulla schermata del bios (sono impostate per effettuare un boot di rete a quanto si capisce dai messaggi visulizzati…) ma questo è colpa dell’incompetenza/non curanza dei tecnici che se ne dovrebbero occupare, suppongo :P

Comunque, sì, mi si gelerebbe il sangue sapendo che il bancomat che sto per utilizzare usa windows :S A questo punto meglio i buoni vecchi bancomat con display monocromatico, e pulsantoni ai lati :P

9. Skipper - 22/03 @ 13:41

Questa forse però non la conoscete in molti:
http://gizmodo.com/5048411/bsod-repeatedly-strikes-nine-inch-nails-concerts

… ma è finta (leggete l’articolo)! :P

10. kyco - 22/03 @ 13:43

>Inserite voi la vostra immagine preferita

http://i.zdnet.com/blogs/largest-adobe-flash-crash-in-the-world.gif

;)

11. amperini - 22/03 @ 13:53

M’è capitato diverse volte di vedere immagini simili.. E i brividi mi vengono veramente a pensarci.. E a pensare a quanti admin idioti esistano.. E al famoso detto:”Finchè va perchè metterci le mani?” e così gli aggiornamenti non vengono mai fatti… Mi vengono i brividi anche se penso a SCADA a dire il vero.. :S

12. bejelit - 22/03 @ 14:02

mah secondo me state guardando il problema dal punto di vista sbagliato
non è che le varie FS, banche, aereoporti, eccetera eccetera, usino window perchè è figo virus friendly e quant’altro …. lo usano semplicemente perchè questo è quello che gli viene passato dai vari “fornitori” … funziona cosi .. spesso e volentieri al partire di un progetto si fa un attività di analisi (si proprio i consulenti informatici … quelli tutti con le giacche grigie e le cravatte grigie che riempono le barzellette) e si riserva all’analisi un buon 60% del budget del progetto ..
e poi ? … be tolte le varie mazzette e altro
con quello che rimane ci si deve pagare tutto: hw & software & sviluppo & manutenzione
e quindi chi offre di meno si aggiudica il lavoro … anche se proprone un interfaccina in visualbasic 6.0 su winNT …

questioni come sicurezza di un sistema operativo, accessibilità? queste cose servono solo a riempire i vari blog su internet (senz’offesa a felipe e a tanti altri che adoro leggere)

13. ManuT - 22/03 @ 14:18

io ho trovato una situazione del genere su una biglietteria automatica in una stazione dei treni…

14. Dani - 22/03 @ 14:19

bejelit servono a riempire i vari blog su internet …e a svuotare i conti correnti della gente. pensaci ;)

felipe c’è addirittura un pool dedicato http://www.flickr.com/groups/[email protected]/pool/

15. ste87 - 22/03 @ 14:32

Anche io ho visto un errore a Roma in stazione Termini (stesso errore del tuo bancomat, circa!) e a milano ho visto addirittura una macchina per fare i biglietti dell’ATM con un windows 2k bloccato al boot (ho anche aspettato un minutino ma nn si muoveva proprio la barra di caricamento hihi).

16. claimid.com/nowhereman - 22/03 @ 15:56

non vorrei dire, ma software di merda ne esiste per qualsiasi piattaforma, così come driver pessimi, e probabilmente ancora di più sviluppatori incompetenti.

A una lettura veloce dell’articolo, a quanto pare il troiano è in grado di scaricare un eseguibile maligno in \Windows, cosa possibile solo se un programma parte con privilegi amministrativi (che significa probabilmente che anche il programma exploitable gira con gli stessi privilegi), sottotitolo STRALOL.

Se il troiano è efficace (e sicuramente lo è), chi lavora su questi ATM dovrebbe darsi a un’occupazione più consona alle proprie capacità, ad esempio l’ippica.

ciao :)

17. linuser - 22/03 @ 16:10

Premetto che per me è una grande fortuna che i sistemi windows siano usati _solo_ per applicazioni non critiche ( non oso pensare a cosa potrebbe succedere se un sistema windows fosse alla base del pilota automatico di un aereo ) , ma la verità è che nessun sistema ( per ora ) è completamente immune da bugs.

Anche i sistemi Unix-like non ne sono e non ne possono essere completamente immuni – ad es. su wikipedia , tra le cause del grande blackout del 2003 che ha coinvolto tutto il nord-america, è citato un bug del sistema di gestione Unix-based della GE ( http://en.wikipedia.org/wiki/Northeast_Blackout_of_2003 , http://www.securityfocus.com/news/8016 ) ….

Persino il cervello umano non è esente da bugs ( strutturali o causati da eventi imprevisti )

A questo punto il nodo centrale del discorso dovrebbe essere : può il modello opensource contribuire a diminuire la presenza di bugs e il loro impatto ( dei bugs critici sopratutto ) nel software usato in produzione ?

Secondo me la risposta è NI :

NO : ad esempio il grave bug che ha afflitto il sistema di generazione delle chiavi ssh , kerberos …etc nei sistemi debian based è persistito ( lol … non so se è completamente corretto in italiano ) per ben 2 anni.

SI : il bug che affliggeva il kernel linux 2.6.27 e che portava alla completa inoperatività delle schede di rete e1000 su alcuni notebook , corretto con il rilascio della versione 2.6.27.1

18. Dodo - 22/03 @ 16:25

@7 Proprio ieri sera ero a Firenze per un concerto e su un autobus ho visto 2 errori eheh

19. tosky - 22/03 @ 17:20

@linuser
Però, per fare un confronto completo con il software chiuso, dovresti poter giudicare a parità di condizioni. Per chiarirci: nel caso del problema di openssl sai tracciare esattamente quello che è successo, ed il tempo in cui il problema è stato presente, cosa che non puoi fare con il software chiuso. Ricordi quando è stata scoperta la backdoor presente nel codice di Interbase/Firebird, proprio grazie all’apertura dei sorgenti? Chissà da quanto tempo era la’ (è un esempio estremo, le backdoor non si trovano tutti i giorni, ma altri tipo di bug sì).

Per tornare in argomento: per questi sistemi, un sistema embedded calza a pennello, per millemila motivi.

20. lolloso - 22/03 @ 17:34

come se un sistema unix non avesse alcuna falla.
ci fosse unix sui bancomat sarebbe esattamente la stessa identica cosa, smettiamola di mirare windows che è “bucato”.

21. sick - 22/03 @ 18:53

anche perché mi sembra si parli di accesso fisico, quindi non è proprio colpa di windows….però l’osservazione di gondsman al 5 è sacrosanta.

22. ste87 - 22/03 @ 19:38

@lolloso
più che ai buchi io penserei ai crash / freeze. Perchè se trovi un terminale che visualizza linux magari vedi una shell o (raro raro) un desktop, semplicemente senza nessun programma avviato (certo magari ha fatto crash e restart e nessuna ha impostato .
Mentre per i terminali con windows vedi i classici BSOD , errori vari o boot frezzati.

23. linuser - 22/03 @ 20:50

@ste87
guarda che se al posto di windows ci fosse linux su quel bancomat , in caso di freeze ( magari , anzi sicuramente evento moooooooooolto più raro ) il risultato è lo stesso perchè l’utente del dispositivo non ha alcun altro tipo di accesso al terminale.

24. tosky - 22/03 @ 20:56

@lolloso
E che cavolo! Si critica lo strumento sbagliato al posto sbagliato. Un’applicazione VB6 (ma anche VB.NET liscio, tantopiù che c’è il Compact Framework) su un sistema operativo _desktop_ (ma anche server) completo in vece di un sistema embedded è una bestialità.

25. NickM - 22/03 @ 21:32

Ottobre 2006, aeroporto di Malpensa di ritorno dal viaggio di nozze.

E’ notte fonda, siamo atterrati e non sappiamo dove arriveranno i nostri bagagli: i monitor del sistema di smistamento mostrano implacabilmente una schermata di un PC che tenta di riavviare il DOS. All’infinito.

26. sito - 22/03 @ 21:43

Io di seri seri ne ho visti pochi ma uno non serio l’ho fotografato in svizzera.

http://www.megaportal.it/imghost/2009/03/22/2156071237755367.gif :D

27. Minkiux - 22/03 @ 21:55

Mi trovi a “fagiuolo”: lavoro per una azienda che produce sistemi di telegestione tramite internet di impianti vari (elettrici, termici, idraulici, ecc). La totalità di essi utilizza pc embedded con una versione custom di linux.
8 anni che faticano e mai un singolo fault :D (se non hardware, tipo una volta in un quadro c’aveva fatto la tana un serpente….)

28. Stefano - 22/03 @ 23:38

eccone uno… tratta venezia-udine…. ma sta volta non è windows… :)

http://www.flickr.com/photos/stefano_ermacora/3377413946/

29. Andreab - 23/03 @ 0:00

ma poi non e’ che crashano per forza.
Basta che nei bancomat “tastiera intera” premi tante volte SHIFT che il bancomat si blocca e ti viene fuori la schermata delle funzioni facilitate…

30. FrAnKHiNrG - 23/03 @ 10:35

Ti quoto in pieno Felipe.

A Gennaio dell’anno scorso, sono stato sottoposto ad un intervento al cuore. Tutto ok ora ma ho dovuto passare una intera settimana in terapia intensiva…più che per l’intervento, la strizza me la sono presa quando ho saputo che il macchinario a cui sono rimasto attaccato in quella settimana girava con windows.

Ho guardato fisso il monitor con i paarametri pensando “ecco, mo appare la schermata blu” :)

31. Murdock - 23/03 @ 10:38

in una ditta una decina di anni fa dovetti dannare per togliere un worm da tutti i pc della rete, compresi 2 magazzini automatizzati a scaffali rotanti alti 10m. Il software girava su windows, con tanto di condivisioni samba.

32. dirac3000 - 23/03 @ 11:44

Fino a un anno e mezzo fa lavoravo in una ditta di software per la logistica marittima negli Stati Uniti. Il software era tutto basato su Windows, MFC, SQL Server 2005 (ora credo abbiano 2008). Cercare di mantenere aggiornato, funzionante e senza bachi il tutto era un’impresa praticamente impossibile, nonostante fossimo in piu’ di 60 sviluppatori lavorando sullo stesso programma. Sviluppare voleva dire sistemare bachi dappertutto, un lavoro francamente frustrante.
Una volta avevo chiesto al direttore dell’azienda se non pensava che una riscrittura del software usando tecniche di programmazione e tecnologie piu’ moderne e sicure non fosse una buona idea. La risposta fu che la quantita’ di soldi, tempo e risorse per fare una cosa del genere erano superiori a quella di mantenere “in vita” un sistema bacato come quello che sviluppavamo. Probabilmente la stessa cosa vale per bancomat, sistemi ospedalieri, uffici pubblici, ecc… (io ho cambiato lavoro :P )

33. Hamcha - 23/03 @ 22:06

ATM ma specialmente macchine ospedaliere dovrebbero montare Firmware Proprietari, non basarsi su OS conosciuti.
Questo vale non solo per Windows, anche per Linux e BSD.
Un os specializzato per la macchina che fa tutto senza l’ausilio di programmi esterni e ristretto abbastanza dall’evitare a virus o errori comuni di compromettere l’intero sistema sarebbe il massimo.

34. Alberto - 24/03 @ 10:10

Se volete rabbrividire davvero, sappiate che esistono in circolazione una grande quantità di dispositivi medicali basati su Windows XP embedded che eseguono software .NET, lavoro nel settore e purtroppo parlo con cognizione di causa.
Credo che il punto stia nel fatto che un programmatore .NET costa generalmente meno di un programmatore GTK+ o QT, quindi…

35. GizMo - 24/03 @ 12:38

x cisO.o il punto della questione che un errore su Linux lo puo’ creare un guasto hardware o una mala progettazione de parte della persona che lo crea, se fai garbuglio nel software e’ possibile, quindi devi essere bravo e questo sighifica che non puoi affidarti su una distribuzione linux qualsiasi per uso desktop senza apportarvi nessuna modifica, a furia di mancamenti di corrente (per dirne una) finisce in errore, devi fare qualcosa di piu’ embeddato e resistente alle torture.

Mentre con Windows… Windows e’ cosi’ com’e', bravo non bravo che tu sia non puoi fare niente di concreto per evitare che vada in crash almeno una volta alla settimana, se non intomellare il coglione che ti li ha comprati perche’ tu possa andare la, pagato, una volta alla settimana a reinstallare tutti i terminali.

36. GizMo - 24/03 @ 12:39

x Alberto, il programmatore .NET costa meno del programmatore QT, ma il tecnico a reinstallare su Windows lo chiami 10 volte + spesso di quello su Linux, vedi mio post sopra.

37. Alberto - 24/03 @ 16:28

x GizMo

Ciao, io parlo di sistemi embedded, che significa che di solito nessuno reinstalla nulla, al massimo si programma una flash o si ripristina l’immagine di un disco fisso. Comunque il punto che volevo evidenziare, più che altro, è che nell’ambito embedded (ci ho lavorato parecchi anni) putroppo certe soluzioni non pagano. Dotarsi una sovrastruttura mastodontica come .NET o come la class library java può risultare certamente comodo per molti programmatori, però più la sovrastruttura è enorme più il rischio che sia buggata aumenta, senza parlare di efficienza. Insomma, nella mia esperienza di sfigato che ha programmato parecchi processori a 20 MHz in C, mi sono spesso meravigliato che per applicazioni piuttosto spartane come un POS si sentisse il bisogno di un ARM a 400 MHz con linux o peggio: di Windows XP Embedded su architettura intel…
Ovviamente è un’esperienza parziale, ma ai tempi del codice C ottimizzato e bruciato sulla eeprom la “fatica” in progettazione era più o meno la stessa, ma la stabilità dell’epoca adesso possiamo sognarcela…
In ogni caso, l’unica azienda (multinazionale) di elettromedicali seria che abbia visto da lontano, sviluppa su linux con interfaccia QT, per la gioia del capo di questo blog (io continuo a preferire GNOME ;) ).
CIAO!

38. GizMo - 25/03 @ 12:02

400mhz, dipende anche dal livello di limatura che viene applicato dal codice, cioe’ quanta roba seghi dal kernel e dalle librerie che hai attorno (ricorda che linux e’ nato su un 386), ma piu’ che altro e’ che quando menzioni le cpu a 20 mhz programmate in c tu non consideri che allora non avevi sotto un sistema operativo con un’applicazione, ma scrivevi un firmware, e solo quello girava nel dispositivo.

Il firmware ha sicuramente pregi di compattezza e velocita’ ma e’ anche piu’ difficile di sviluppare e forse meno flessibile, sopratutto di fronte alle modifiche.

Oggi fare una cpu a 20mhz non costa meno di fare una cpu a 400, quindi non c’e’ la necessita’ di ottimizzare cosi’ tanto. Io ti dico la mia misera esperienza:

Ho una console da gioco GP2x con linux sopra che attualmente uso essenzialmente come lettore mp3 nel mio laboratorio privato dove per hobby costruisco e/o provo amplificatori a valvole, ovviamente la console la uso come sorgente audio, sai quante volte mi si sono scaricate le pile mentre andava? Ma non e’ mai successo niente, cambiavo le pile e la riaccendevo.

Di contro il mio navigatore GPS con windows CE.NET sai quanti cancheri ma fatto tirare nella mia vita? Ho dovuto piu’ volte reinstallare il software per non parlare del simpatico buco (forse tutto suo) che se uso una SD da 1Gb o superiore dopo 2 o 3 volte che lo spengo e riaccendo mi caccia errore, perche’ la SD in FAT32 risulta piena di errori, completamente compromessa da riformattare perche’ inleggibile. Questo baco ma costretto a procurarmi una SD da 512mega usata su ebay (la sua SD originaria era da 512mega, si era rotta e la avevo cambianta con una da 1 giga, da 512 non si trovavano piu’).

Il GPS l’ho pagato 550euro, la gp2x meno della meta’. Il mio prossimo GPS sara’ sicuramente un tomtom con Linux perche’ io di windows CE embeddato ne ho proprio pieni i MAR…

39. GizMo - 25/03 @ 12:06

tra parentesi, le QT sono moooooooooooolto piu’ avanti delle GTK sia dal lato della programmabilita’ che dal lato della portabilita’.

le GTK fanno ridere, hai le gtk su windows e anche su Linux, ma se fai un programma in GTK su windows non lo riesci a portare direttamente su Linux, conosco un programmatore che aveva fatto un gestionale in GTK su windows che mi disse che su Linux faceva prima a riscrivere tutto da 0 che a portare il suo programma dalle GTK Win alle GTK Lin. Fatto sta che questo gestio non fu mai portato su Linux. (e non e’ perche’ lui usava anche parti di windows, ma proprio differenze madornali tra le 2 versioni di GTK).

Le QT invece sono dirette, se usi solo la libreria QT e basta il sorgente lo compili di qua e di la senza modifiche.

40. Alberto - 27/03 @ 13:45

In ambito embedded non ha proprio senso di preoccuparsi di usare librerie cross-platform, no? Tutti sembrano impazziti con il cross-platform, ma non è che *ogni* applicazione a priori debba esserlo.
Le GTK non fanno ridere, sono una libreria molto snella per essere autosufficiente, le QT hanno ovviamente un tipo di ambizione diversa, in quanto framework sempre più complessivo per costruire applicazioni, però poi ovviamente il look è quello che è… Opera è carino, ma non sembra nativo sotto alcun ambiente operativo, insomma, anche se ci si incolla sopra una skin. Poi ripeto: non si può paragonare GTK a QT in termini di funzionalità e scopo.
Quando i programmatori impareranno a tener ben separato il nucleo del software dall’interfaccia ci saranno meno psicosi derivanti dal toolkit.
Dal lato della programmabilità a me non pare che QT siano più “avanti”, con l’obbligo di usare macro e preprocessori non standard.
I pacchetti multipiattaforma più usati alla fine sono Firefox e OpenOffice.org, quindi java a manetta, XUL e tutto il resto, niente GTK ne QT, giusto?
Poi sulla cosa che dicevi del navigatore su Windos Mobile sono pienamente d’accordo: è allucinante che ad oggi tutte le piattaforme mobili (spero bene per Android e WebOS) siano così zeppe di bug, ma se i tempi di sviluppo dei prodotti non superano i sei mesi cosa possiamo aspettarci? L’industria sta andando a…