Skip to content

csagent-excelfix

Choose a tag to compare

View all tags
@artydev artydev released this 15 Oct 20:58
· 15 commits to main since this release
v0.9.12
68ed161

CsAgent 0.9.12 — notes de version

La version 0.9.12 corrige un faux blocage du filtre de commandes : excel_command refusait $ws.Range("E2:E31").NumberFormat = "0.00" comme « potentiellement dangereux ». Elle fait suite à la 0.9.11.

Résumé

Domaine Ce qui change
Filtre des commandes Un motif ne compte qu'en début de mot : NumberFormat n'est plus pris pour format, git add n'est plus pris pour dd
Messages de refus Ils nomment le motif bloqué (blocked pattern 'format') dans sh, run_terminal et excel_command
Tests 285 tests (4 de plus)

Aucun argument, variable d'environnement ni fichier de configuration n'est ajouté.

Notes de mise à jour

  1. Le filtre est moins strict sur un point précis : un motif qui commence par une lettre n'est plus cherché au milieu d'un mot. Tous les motifs de la liste restent bloqués quand ils sont utilisés comme commande ou comme argument.
  2. La liste des motifs ne change pas. Les motifs qui commencent par un séparateur de chemin (\windows\system32\, /etc/…) restent cherchés n'importe où dans le texte.
  3. Le message de refus change de forme : Error: excel_command - command contains the blocked pattern 'format' (potentially dangerous operations) and is not allowed. Rewrite the command…. Le début (Error: <outil> -) et les mots « not allowed » sont conservés.

Le problème

Sous Windows, le filtre cherchait le texte format n'importe où dans la commande, en minuscules, pour bloquer format c:. Or .NumberFormat = "0.00" contient format (le mot est suivi d'un espace). Mettre un format de nombre sur des cellules Excel était donc refusé, quelle que soit la façon d'écrire la commande (guillemets simples ou doubles : l'agent essayait les deux, sans effet). Le message ne disait pas quel motif posait problème, donc l'agent ne pouvait pas deviner.

Le même défaut existait sous Linux et macOS : git add fichier contient dd et était refusé par sh.

Le correctif

  • Un motif qui commence par une lettre ne compte qu'au début d'un mot : le caractère qui le précède ne doit être ni une lettre, ni un chiffre, ni _, ., $ ou -.
  • format c:, echo x & format c:, cmd /c format e: restent bloqués ; .NumberFormat = "0.00" et .Cells.NumberFormat.ToString() passent.
  • Le message nomme le motif trouvé.

Limites

  • Le filtre lit toujours le texte de la commande, y compris entre guillemets. Une cellule Excel dont la valeur est "format c:" reste bloquée, puisqu'elle ressemble à la commande. Le message le dit : il faut reformuler. Ignorer le texte entre guillemets dans excel_command a été envisagé puis écarté : il ajoute du code de sécurité et une liste noire de lanceurs pour un cas qui ne s'est pas présenté. À reprendre si le cas se présente.
  • Le filtre n'est pas un analyseur de commandes : il ne protège pas contre une commande volontairement obfusquée. C'est un garde-fou contre les erreurs, pas une barrière de sécurité.
  • Non corrigé, car hors du sujet : sous Linux et macOS, /bin/ est aussi cherché dans un chemin comme ./bin/Debug/app.dll, qui est donc refusé par sh.
  • Pas essayé avec un vrai Excel : l'environnement de développement est sous Linux. Les tests couvrent le filtre, pas l'appel COM.

Tests

285 tests (dotnet run --project Tests -c Release), dont les 4 nouveaux (CommandFilterTests.cs) :

  • Windows : .NumberFormat (guillemets simples et doubles, plusieurs instructions), .Font.Bold et .Cells.NumberFormat.ToString() passent ;
  • Windows : format c: est bloqué au début, après & ou ;, dans cmd /c, ou entre guillemets ; ainsi que reg delete, net user, shutdown, del /f et \windows\system32\ ;
  • Linux et macOS : git add passe, dd if=…, sudo, chmod, /etc/, mkfs et reboot restent bloqués ;
  • le refus nomme le motif dans excel_command, sh et run_terminal, et garde les mots « not allowed » ;
# CsAgent 0.9.12 — notes de version

La version 0.9.12 corrige un faux blocage du filtre de commandes : excel_command refusait $ws.Range("E2:E31").NumberFormat = "0.00" comme « potentiellement dangereux ». Elle fait suite à la 0.9.11.

Résumé

Domaine Ce qui change
Filtre des commandes Un motif ne compte qu'en début de mot : NumberFormat n'est plus pris pour format, git add n'est plus pris pour dd
Messages de refus Ils nomment le motif bloqué (blocked pattern 'format') dans sh, run_terminal et excel_command
Tests 285 tests (4 de plus)

Aucun argument, variable d'environnement ni fichier de configuration n'est ajouté.

Notes de mise à jour

  1. Le filtre est moins strict sur un point précis : un motif qui commence par une lettre n'est plus cherché au milieu d'un mot. Tous les motifs de la liste restent bloqués quand ils sont utilisés comme commande ou comme argument.
  2. La liste des motifs ne change pas. Les motifs qui commencent par un séparateur de chemin (\windows\system32\, /etc/…) restent cherchés n'importe où dans le texte.
  3. Le message de refus change de forme : Error: excel_command - command contains the blocked pattern 'format' (potentially dangerous operations) and is not allowed. Rewrite the command…. Le début (Error: <outil> -) et les mots « not allowed » sont conservés.

Le problème

Sous Windows, le filtre cherchait le texte format n'importe où dans la commande, en minuscules, pour bloquer format c:. Or .NumberFormat = "0.00" contient format (le mot est suivi d'un espace). Mettre un format de nombre sur des cellules Excel était donc refusé, quelle que soit la façon d'écrire la commande (guillemets simples ou doubles : l'agent essayait les deux, sans effet). Le message ne disait pas quel motif posait problème, donc l'agent ne pouvait pas deviner.

Le même défaut existait sous Linux et macOS : git add fichier contient dd et était refusé par sh.

Le correctif

  • Un motif qui commence par une lettre ne compte qu'au début d'un mot : le caractère qui le précède ne doit être ni une lettre, ni un chiffre, ni _, ., $ ou -.
  • format c:, echo x & format c:, cmd /c format e: restent bloqués ; .NumberFormat = "0.00" et .Cells.NumberFormat.ToString() passent.
  • Le message nomme le motif trouvé.

Limites

  • Le filtre lit toujours le texte de la commande, y compris entre guillemets. Une cellule Excel dont la valeur est "format c:" reste bloquée, puisqu'elle ressemble à la commande. Le message le dit : il faut reformuler. Ignorer le texte entre guillemets dans excel_command a été envisagé puis écarté : il ajoute du code de sécurité et une liste noire de lanceurs pour un cas qui ne s'est pas présenté. À reprendre si le cas se présente.
  • Le filtre n'est pas un analyseur de commandes : il ne protège pas contre une commande volontairement obfusquée. C'est un garde-fou contre les erreurs, pas une barrière de sécurité.
  • Non corrigé, car hors du sujet : sous Linux et macOS, /bin/ est aussi cherché dans un chemin comme ./bin/Debug/app.dll, qui est donc refusé par sh.
  • Pas essayé avec un vrai Excel : l'environnement de développement est sous Linux. Les tests couvrent le filtre, pas l'appel COM.

Tests

285 tests (dotnet run --project Tests -c Release), dont les 4 nouveaux (CommandFilterTests.cs) :

  • Windows : .NumberFormat (guillemets simples et doubles, plusieurs instructions), .Font.Bold et .Cells.NumberFormat.ToString() passent ;
  • Windows : format c: est bloqué au début, après & ou ;, dans cmd /c, ou entre guillemets ; ainsi que reg delete, net user, shutdown, del /f et \windows\system32\ ;
  • Linux et macOS : git add passe, dd if=…, sudo, chmod, /etc/, mkfs et reboot restent bloqués ;
  • le refus nomme le motif dans excel_command, sh et run_terminal, et garde les mots « not allowed » ;
Assets 3
Loading