Problema di sicurezza nella gestione dei segnali in Python

[Mario Alexandro Santini]

Ciao,

se c'è qualche esperto di Python in lista, vorrei sottoporgli un problema che sto analizzando.

Ho un servizio che gira in un Docker container all'interno di un cluster  ed ho la necessità di poterlo stoppare con un SIGTERM.

Per questo motivo ho un modulo che intercetta il segnale e solleva un eccezione, che poi gestisco per far uscire il servizio in maniera corretta.

Ecco qui il codice semplificato del mio modulo:

def handler(signum, frame):
  LOG.info(f"Catched signal {signum} - {signal.Signals(signum).name}")

  if signum == signla.SIGTERM:
    LOG.info(f"Raise KeyboardInterrupt as received {signal.Signals(signum).name}")

    raise KeyboardInterrupt('Received SIGTERM')

def init():
  signal.signal(signal.SIGTERM, handler)

Poi nel file principale:

if __name__ == "__main__":
    LOG.info("Starting ...")
    signal_handler.init()

    try:
        main(sys.argv[1:])
    except KeyboardInterrupt:
        sys.exit(0)
    finally:
        sys.exit(2)

Ora, nella fase di build del servizio, abbiamo un analizzatore statico del codice, che mi segnala un problema grave sulla seguente riga:

  signal.signal(signal.SIGTERM, handler)

Sostiene che c'è un problema: "Information Leakage-Signal (Python)"

Ed in particolare, la riga è "Suspicious capturing of signal events [signal.signal]"

Ho fatto un po' di ricerche, ma non sono riuscito a trovare granché per migliorare questo codice e risolvere il problema segnalato.

Chiedo a chi è più esperto di me in Python, se ho dimenticato qualche best practice o anche un riferimento di documentazione utile a risolvere questo problema.

Vi ringrazio per l'aiuto,

Mario

[Chris Mair]

>
> Ora, nella fase di build del servizio, abbiamo un analizzatore statico del codice, che mi segnala un problema grave sulla seguente riga:
>
> signal.signal(signal.SIGTERM, handler)
>
> Sostiene che c'è un problema: "Information Leakage-Signal (Python)"
> Ed in particolare, la riga è "Suspicious capturing of signal events [signal.signal]"
>
> Ho fatto un po' di ricerche, ma non sono riuscito a trovare granché per migliorare questo codice e risolvere il problema segnalato.
>
> Chiedo a chi è più esperto di me in Python, se ho dimenticato qualche best practice o anche un riferimento di documentazione utile a risolvere questo problema.
>

Non sono un esperto di Python. Ma non ci vedo assolutamente
niente di male. Trappi il normale KILL (signal 15) perché intendi
fare del clean up.

Secondo me è la solita static analysis che vede fantasmi. Se devi
trappare kill, lo devi trappare.

Ho visto sistemi anche andare in panico se apri un client socket...
Va beh, devo accedere alla rete, cosa devo fare?

Bye,
Chris

[Mario Alexandro Santini]

On Wed, Oct 9, 2024 at 12:02 PM 'Chris Mair' via Socraten <socr...@googlegroups.com> wrote:

Non sono un esperto di Python. Ma non ci vedo assolutamente
niente di male. Trappi il normale KILL (signal 15) perché intendi
fare del clean up.

Secondo me è la solita static analysis che vede fantasmi. Se devi
trappare kill, lo devi trappare.

Ho visto sistemi anche andare in panico se apri un client socket...
Va beh, devo accedere alla rete, cosa devo fare?

Ciao Chris,

grazie per la risposta.

A volte è possibile indicare l'anomalia come un falso positivo.

In questo caso penso che lo sia, perché non riesco a vedere come questo codice possa essere "pericoloso" in qualche modo.

Volevo solo essere ragionevolmente sicuro che fosse così.

:)

Bye,
Chris

Mario

[Chris Mair]

> Ciao Chris,
>
> grazie per la risposta.
>
> A volte è possibile indicare l'anomalia come un falso positivo.
>
> In questo caso penso che lo sia, perché non riesco a vedere come questo codice possa essere "pericoloso" in qualche modo.
>
> Volevo solo essere ragionevolmente sicuro che fosse così.
> :)
>

Ma, sicuramente se è codice NON TUO che deposita un signal handler
potrebbe avere secondi scopi (c'erano exploit basati sul signal handling
da parte del kernel) e/o fare casino (già il non uscire al kill da solo
potrebbe essere un comportamento non voluto).

Loro poi ti parlano di "Information Leakage-Signal (Python)". Posso immaginare
che un codice evil potrebbe usare i signal per fare comunicazione tra processi
che non dovrebbero essere altrimenti in grado di scambiarsi informazioni?
O forse leggo male io.

In ogni caso, qui sei TU a definire quel handler e hai motivi per averne
bisogno. Quindi sì, per me questo è un falso positivo.

Bye,
Chris.

[Mario Alexandro Santini]

On Wed, Oct 9, 2024 at 12:37 PM 'Chris Mair' via Socraten <socr...@googlegroups.com> wrote:

In ogni caso, qui sei TU a definire quel handler e hai motivi per averne
bisogno. Quindi sì, per me questo è un falso positivo.

Già, l'analizzatore statico dovrebbe accorgersi di questo.

Tanto più che gestisco un unico segnale, che è poi cablato.

Grazie per la conferma della mia ipotesi, ci faccio ancora qualche ricerca sopra e se non scopro nulla lo metto come falso positivo.

Se scopro qualcosa, invece, aggiorno il thread.

 

Bye,
Chris.

Mario