Linux a rischio, scoperta grave falla di sicurezza

[Claudio F]

Articolo di Punto Informatico del 02/02/2024. Ho sempre saputo che per correttezza quando si scopre una vulnerabilità, prima di tutto di deve informare chi gestisce il codice, il quale quando ha fatto le correzioni dovute, informerà gli urenti per l’installazione degli aggiornamenti, solo se i gestori del codice non intervengono, si può rendere di pubblico dominio la falla. Chiedo di sapere perché di questo articolo “Linux a rischio”. Forse che Linux, Debian, Fedora e Ubuntu, non sono intervenuti o altro o c'è un'altra spigazione.

[GjMan78]

Credo che l'approccio a cui ti riferisci sia quello da tenere in caso di software closed source.

Nel mondo open i bug sono pubblici quanto lo è il codice, è così che le vulnerabilità vengono risolte.

Inoltre il bug non riguarda direttamente i sistemi operativi citati ma si tratta di una falla di specifiche versioni della libreria glibc (GNU C) quindi le distro hanno poca voce in capitolo, dovranno soltanto aggiornare la suddetta libreria alla nuova versione non appena sarà patchata.

E come al solito Punto Informatico arriva in ritardo, la notizia circola già da almeno 2 giorni
https://www.redhotcyber.com/post/linux- ... ribuzioni/

[woddy68]

Di solito quell'approccio si utilizza a prescindere se è close o open, è buona norma attendere che vengono effettuati e spediti i fix, prima di pubblicare il bug, tuttavia questa non è una regola scritta è solo una norma di buonsenso che è appunto diventata una "norma".

[GjMan78]

E comunque questa è la timeline del bug, dalla scoperta alla divulgazione passando per la segnalazione a RedHat.

Codice: Seleziona tutto

========================================================================
Timeline
========================================================================

2023-11-07: We sent a preliminary draft of our advisory to Red Hat
Product Security.

2023-11-15: Red Hat Product Security acknowledged receipt of our email.

2023-11-16: Red Hat Product Security asked us if we could share our
exploit with them.

2023-11-17: We sent our exploit to Red Hat Product Security.

2023-11-21: Red Hat Product Security confirmed that our exploit worked,
and assigned CVE-2023-6246 to this heap-based buffer overflow in
__vsyslog_internal().

2023-12-05: Red Hat Product Security sent us a patch for CVE-2023-6246
(written by the glibc developers), and asked us for our feedback.

2023-12-07: While reviewing this patch, we discovered two more minor
vulnerabilities in the same function (an off-by-one buffer overflow and
an integer overflow). We immediately sent an analysis, proof of concept,
and patch proposal to Red Hat Product Security, and suggested that we
directly involve the glibc security team.

2023-12-08: Red Hat Product Security acknowledged receipt of our email,
and agreed that we should directly involve the glibc security team. We
contacted them on the same day, and they immediately replied with very
constructive comments.

2023-12-11: The glibc security team suggested that we postpone the
coordinated disclosure of all three vulnerabilities until January 2024
(because of the upcoming holiday season). We agreed.

2023-12-13: Red Hat Product Security assigned CVE-2023-6779 to the
off-by-one buffer overflow and CVE-2023-6780 to the integer overflow in
__vsyslog_internal().

2024-01-04: We suggested either January 23 or January 30 for the
Coordinated Release Date of these vulnerabilities. The glibc developers
agreed on January 30.

2024-01-12: The glibc developers sent us an updated version of the
patches for these vulnerabilities.

2024-01-13: We reviewed these patches, and sent our feedback to the
glibc developers.

2024-01-15: The glibc developers sent us the final version of the
patches for these vulnerabilities.

2024-01-16: We sent these patches and a draft of our advisory to the
linux-distros@openwall. They immediately acknowledged receipt of our
email.

2024-01-30: Coordinated Release Date (18:00 UTC).

https://seclists.org/oss-sec/2024/q1/68

[kessler]

"Linux a rischio, scoperta grave falla di sicurezza". Poi apri l'articolo e scopri che la falla riguarda glibc.

Evidentemente chi (non) linka questi articoli non si rende conto della quantità di falle anche gravi che mensilmente vengono scoperte e fixate, ringraziando l'allarmismo suscitato da certi titoli bait... Basterebbe iscriversi (o anche solo dare un'occhiata) alla mailing list ubuntu-security-announce per farsi un'idea.
https://lists.ubuntu.com/archives/ubunt ... -announce/

Il discorso è sempre lo stesso: se ci si fida del proprio "fornitore" (la distro che si utilizza) basta tenerla aggiornata regolarmente, e non serve preoccuparsi o allarmarsi per qualcosa che in effetti è già stato fixato. Le patch ad alta priorità vengono distribuite quasi istantaneamente, quindi basta un sudo apt update && sudo apt dist-upgrade per stare tranquilli.

[Filoteo]

Tanto rumore per vulnerabilità specifiche quando bug di sicurezza gravi sono all'ordine del giorno, ad esempio nel kernel linux ne vengono scoperti centinaia ogni mese (non risolti poi). Ciononostante, a meno di essere presi di mira personalmente, su Linux si è abbastanza sicuri data la sua irrilevanza sul desktop e quindi lo scarso interesse da parte di hacker malintenzionati.

[Insane69x]

"Ciononostante, a meno di essere presi di mira personalmente, su Linux si è abbastanza sicuri data la sua irrilevanza sul desktop e quindi lo scarso interesse da parte di hacker malintenzionati."

Chiedo scusa ma sono "vergine" in ambito Linux, ma avrei una domanda in merito alla citazione sopra riportata:
Se è vero che Linux è open source è anche vero che in linea teorica ogni utente potrebbe modificare il kernel, una volta sicuri della "relativa" sicurezza della connessione, che tipo di attacco potrebbe arrivare a segno?