SpeakUp, il trojan invisibile agli antivirus

[pabloski]

Originariamente inviato da fano

Lo sai vero che PS4 non è altro che un PC con hardware un po' particolare in cui gira Net BSD?

FreeBSD.

[zappy]

Originariamente inviato da pabloski

FreeBSD.

quindi fatemi capire... il porting dei giochi su linux &C è un gioco da ragazzi...

[pabloski]

Originariamente inviato da zappy

linux ce l'ho a casa sulla mia macchina, quindi come viene gestito un server aziendale non m'interessa.
chiedevo chiarimenti su come si può migliorare la sicurezza su una macchina casalinga, visto che ho notato che /tmp è x per tutti.
Se vuoi fornire chiarimenti bene, oppure me ne farò una ragione

Una cosa del genere ( in /etc/fstab )

tmpfs       /tmp                    tmpfs    defaults,nodev,nosuid,noexec        0 0

Il noexec elimina ogni possibilità di eseguire roba da /tmp. tmpfs la mette in ram, così viene flushata ad ogni riavvio.

Però io preferisco una soluzione nettamente migliore. Questa

/dev/nvme0n1p2 on /run/miso/bootmnt type ext4 (ro,relatime)
cowspace on /run/miso/cowspace type tmpfs (rw,relatime,size=262144k,mode=755)
overlay_root on /run/miso/overlay_root type tmpfs (rw,relatime,mode=755)
/dev/loop0 on /run/miso/sfs/livefs type squashfs (ro,relatime)
overlay on / type overlay (rw,relatime,lowerdir=/run/miso/sfs/livefs,upperdir=/run/miso/overlay_root/upper,workdir=/run/miso/overlay_root/work)

In parole povere, l'intero root filesystem è montato read-only a partire da un'immagine squashfs. La parte write è un overlay in ram.

Non aiuta in generale ad evitare infezioni, elimina però qualsiasi possibilità di persistenza del malware. Cioè ad ogni riavvio si è sicuri che il sistema sia 100% pulito. E' una buona soluzione per un sistema da usare per l'home banking, magari su una pendrive.

[pabloski]

Originariamente inviato da zappy

quindi fatemi capire... il porting dei giochi su linux &C è un gioco da ragazzi...

Non credo. E' come per Android. C'è il kernel Linux ma un userland completamente differente.

Non è nemmeno dato sapere che PS4 e precedenti implementano le specifiche OpenGL o qualcosa di simile ma diverso e proprietario.

Orbis ( l'OS di PS4 ) ha il kernel FreeBSD, una serie di librerie utili ( tipo OpenSSL ), forse qualche comando dell'userland ( tipo mount, ip, ecc... ), ma il resto è roba proprietaria Sony. Soprattutto la parte che riguarda la grafica 3D e il suono.

[fano]

Ovviamente il driver per la GPU è proprietario, ma comunque sì è possibile far girare Linux su PS4 eccome se è possibile, gli emulatori fino al N64 vanno (quello dello Wii per ora va a 20 FPS), Steam funziona e persino Wine!

Il driver Linux ha pure accelerazione hardware facendo un "porting" dai driver opensource di X...

https://www.youtube.com/watch?v=02fx1Zhs-c0&vl=en

[pabloski]

Originariamente inviato da fano

Ovviamente il driver per la GPU è proprietario

Ed è la parte comica. Un driver FreeBSD per GPU Radeon, che non è mai arrivato nell'ecosistema FreeBSD. Tant'è che FreeBSD ancora oggi si sbatte per fare il porting ( alla meno peggio ) dei driver Radeon per Linux.

Sono queste le situazioni che mi hanno fatto propendere per la GPL. Sarà virale e rompiscatole per le multinazionali, ma almeno segue la logica del "'ca nisciun è fess".

[acerbo]

Originariamente inviato da zappy

linux ce l'ho a casa sulla mia macchina, quindi come viene gestito un server aziendale non m'interessa.
chiedevo chiarimenti su come si può migliorare la sicurezza su una macchina casalinga, visto che ho notato che /tmp è x per tutti.
Se vuoi fornire chiarimenti bene, oppure me ne farò una ragione

Nel tuo precedente post piu' che porre una questione avevo l'impressione che stessi rispondendo ...
Comunque nessun problema, te lo spiego molto semplicemente.

Lo /tmp é di fatto un porto franco dove spesso le applicazioni vanno a scrivere e ad eseguire procressi perché, appunto, é un FS che si presta a questo e ti evita di avere errori di permission denied quando vuoi installare o lanciare qualcosa senza parametrare la directory di lavoro.
Ora cio' che succede nella normalità é che /tmp é accessibile a tutti, quindi un utente qualsiasi se esegue un codice o installa un'applicazione che ha bisogno di un'area "tampone" per eseguirsi o installarsi andrà in /tmp.
Cio' che puo' succedere é che un software malevolo puo' utilizzare tmp per eseguire codice senza che l'utente se ne accorga e sui server é buona regola montare lo /tmp senza permessi di esecuzione.
Su un pc montare/tmp in noexec é fattibile ma piu' complicato da gestire perché rispetto ad un server sei piu' soggetto ad installare applicazioni e quindi ti tocca ogni volta parametrarle e cambiare il percorso di default da /tmp a $HOME/tmp per esempio, ma non é manco detto che tutte le appllicazioni che installi abbiano questa opzione.
Ad ogni modo dubito che sul computer di casa ci metti su un webserver con php

[zappy]

Originariamente inviato da pabloski

Una cosa del genere ( in /etc/fstab )

tmpfs       /tmp                    tmpfs    defaults,nodev,nosuid,noexec        0 0

Il noexec elimina ogni possibilità di eseguire roba da /tmp. tmpfs la mette in ram, così viene flushata ad ogni riavvio.

ok, capito. però non basta "pulire" /tmp anche se è su disco e non in ram?

Però io preferisco una soluzione nettamente migliore. Questa

/dev/nvme0n1p2 on /run/miso/bootmnt type ext4 (ro,relatime)
cowspace on /run/miso/cowspace type tmpfs (rw,relatime,size=262144k,mode=755)
overlay_root on /run/miso/overlay_root type tmpfs (rw,relatime,mode=755)
/dev/loop0 on /run/miso/sfs/livefs type squashfs (ro,relatime)
overlay on / type overlay (rw,relatime,lowerdir=/run/miso/sfs/livefs,upperdir=/run/miso/overlay_root/upper,workdir=/run/miso/overlay_root/work)

In parole povere, l'intero root filesystem è montato read-only a partire da un'immagine squashfs. La parte write è un overlay in ram.

Non aiuta in generale ad evitare infezioni, elimina però qualsiasi possibilità di persistenza del malware.

qua capisco meno.... monti TUTTO il fs in ram?!?
e quanti terabyte di ram devi installare?!?
penso di aver capito male...

Originariamente inviato da acerbo

...Lo /tmp é di fatto un porto franco dove spesso le applicazioni vanno a scrivere
...
Ora cio' che succede nella normalità é che /tmp é accessibile a tutti, quindi un utente qualsiasi se esegue un codice o installa un'applicazione che ha bisogno di un'area "tampone" per eseguirsi o installarsi andrà in /tmp.
Cio' che puo' succedere é che un software malevolo puo' utilizzare tmp per eseguire codice senza che l'utente se ne accorga e sui server é buona regola montare lo /tmp senza permessi di esecuzione.

Su un pc montare/tmp in noexec é fattibile ma piu' complicato da gestire perché rispetto ad un server sei piu' soggetto ad installare applicazioni e quindi ti tocca ogni volta parametrarle e cambiare il percorso di default da /tmp a $HOME/tmp per esempio, ma non é manco detto che tutte le appllicazioni che installi abbiano questa opzione.
Ad ogni modo dubito che sul computer di casa ci metti su un webserver con php

ah, ecco. mi pareva che andasse bene per server dove aggiorni solo un pacchetto alla volta ogni mese... ma non per un homepc dove ogni giorno l'updater scarica ed installa decine di librerie, applicazioni, office, browser, client vari, X, mesa e compagnia cantando...
in queste situazioni impedire l'esecuzione in /tmp mi sa che inchioderebbe tutto in meno di 5 minuti.
ok, quindi per un caso "normale" è corretto che /tmp sia x. Eventualmente è utile che lo sia solo per utente e gruppo, e non per altri? O ci si cerca rogne lostesso?

[acerbo]

Originariamente inviato da zappy

ah, ecco. mi pareva che andasse bene per server dove aggiorni solo un pacchetto alla volta ogni mese... ma non per un homepc dove ogni giorno l'updater scarica ed installa decine di librerie, applicazioni, office, browser, client vari, X, mesa e compagnia cantando...
in queste situazioni impedire l'esecuzione in /tmp mi sa che inchioderebbe tutto in meno di 5 minuti.
ok, quindi per un caso "normale" è corretto che /tmp sia x. Eventualmente è utile che lo sia solo per utente e gruppo, e non per altri? O ci si cerca rogne lostesso?

in realtà i pacchetti installati via yum, apt, ecc non hanno bisogno dello /tmp, sono piu' che altro applicazioni di terze parti, tipo i programmi java che pero' nel 90% dei casi sono configurabili e puoi modificare la temp dir.
Comunque ripeto, qua si parla di un exploit che sfrutta l'httpd+php, nessun pc con linux, a parte qualche macchina di sviluppo, avrà un demone http installato e attivo.
Come al solito i rischi sulla sicurezza sono piu' teorici che reali e la psicosi dell'utente medio fa bene solo alle software house che vendono gli antivirus e soluzioni complementari e sono spesso le stesse software house che sviluppano questi malware/trojan

[zappy]

Originariamente inviato da acerbo

in realtà i pacchetti installati via yum, apt, ecc non hanno bisogno dello /tmp, sono piu' che altro applicazioni di terze parti, tipo i programmi java che pero' nel 90% dei casi sono configurabili e puoi modificare la temp dir.
Comunque ripeto, qua si parla di un exploit che sfrutta l'httpd+php, nessun pc con linux, a parte qualche macchina di sviluppo, avrà un demone http installato e attivo.
Come al solito i rischi sulla sicurezza sono piu' teorici che reali e la psicosi dell'utente medio fa bene solo alle software house che vendono gli antivirus e soluzioni complementari e sono spesso le stesse software house che sviluppano questi malware/trojan

che l'articolo parli di "linux" ma in realtà il problema sia di altro, mi è chiaro.
quel che non ho capito è se serve, su una macchian domestica, disabilitare x su /tmp o se si rischia solo di far incastrare qualche sw o script che si aspetta una configurazione standard. che apt già non abbia problemi mi solleva, ma altri?
guardando la mia /tmp ora c'è una cartella dell'updater che contiene una specie di log, una cartella mozilla, una ssh, un po' di systemd-private (cui non fa accedere ) un paio di temp con dentro roba di mesa , una decina di file xpi...