robert/todo
Watch
1
0
Fork
You've already forked todo
 0
Code Issues 3 Pull requests Projects Releases Packages 1 Wiki Activity Actions

ImageSharp 3.1.12: BigTIFF-DoS beim Bild-Upload und EXIF/GPS-Leck in Avataren absichern #241

New issue
Closed
opened 2026-10-08 21:47:12 +02:00 by lena · 2 comments
lena commented 2026-10-08 21:47:12 +02:00
Collaborator
Copy link

Hintergrund

dotnet build meldet NuGet-Audit-Warnungen (NU1902/NU1903) für SixLabors.ImageSharp 3.1.12: GHSA-gwg2-r3hj-4w44, GHSA-wmxv-xphr-5c9g (moderat), GHSA-j3p4-wp97-rph4, GHSA-j9gm-c75j-xc9q, GHSA-jjfr-hcj7-qf5w (hoch). Gefixt erst in 4.1.2 (Lizenzschlüssel nötig), es gibt keinen 3.x-Fix.

Analyse (wie Checkly ImageSharp nutzt)

ImageSharp wird nur in Checkly/Uploads/ImageUploadValidator.cs (Avatar-Upload, KI-Produktfoto-Erkennung) verwendet.

  • GHSA-wmxv-xphr-5c9g (BigTIFF-Endlosschleife): erreichbar. Image.Identify läuft mit der Default-Konfiguration (alle Decoder inkl. TIFF) vor der JPEG/PNG/WebP-Allowlist. Nachgestellt mit 3.1.12: eine 24-Byte-BigTIFF hält Identify > 8 s (praktisch unbegrenzt, ~2^56 Iterationen) auf einem Thread fest, nicht abbrechbar. Jeder eingeloggte Nutzer kann das über den Avatar-Upload auslösen.
  • GHSA-gwg2-r3hj-4w44 (ICC-CLUT): in 3.x nur über IccProfile.Entries erreichbar, das Checkly nie aufruft.
  • GHSA-j3p4-wp97-rph4 (HistogramEqualization), GHSA-j9gm-c75j-xc9q / GHSA-jjfr-hcj7-qf5w (TIFF-CCITT-Encoder): nicht erreichbar, Checkly nutzt weder HistogramEqualization noch einen TIFF-Encoder.

Zusatzbefund (Datenschutz-Bug): Entgegen den Code-Kommentaren bleiben EXIF-Daten (inkl. GPS) beim Re-Encoding erhalten (nachgestellt: EXIF überlebt Load -> Resize -> JPEG/WebP). Avatare sind für andere Listenmitglieder sichtbar; das an den KI-Anbieter geschickte Foto enthält ebenfalls EXIF (verletzt Security-Pre-Review-Punkt 2 von #95).

Entscheidung (Mensch, 2026-10-08)

Option (c): bei 3.1.12 bleiben, Risiko mit Mitigationen akzeptieren. (Alternativen: Migration auf SkiaSharp, ImageSharp-4-Lizenz kaufen.)

Akzeptanzkriterien

  • Upload-Decoding nutzt eine Konfiguration nur mit JPEG/PNG/WebP-Decodern (auch für Identify); eine BigTIFF-Datei wird sofort abgelehnt.
  • Vor dem Speichern/Weitergeben werden alle Metadaten-Profile (EXIF, XMP, ICC, IPTC) entfernt - gilt für Avatar und KI-Foto.
  • Die fünf Advisories werden gezielt per NuGetAuditSuppress mit Begründung unterdrückt (neue Advisories bleiben sichtbar).
  • Tests: BigTIFF wird abgelehnt (mit Timeout), EXIF ist im gespeicherten Avatar und im KI-JPEG nicht mehr enthalten.
## Hintergrund `dotnet build` meldet NuGet-Audit-Warnungen (NU1902/NU1903) für `SixLabors.ImageSharp` 3.1.12: GHSA-gwg2-r3hj-4w44, GHSA-wmxv-xphr-5c9g (moderat), GHSA-j3p4-wp97-rph4, GHSA-j9gm-c75j-xc9q, GHSA-jjfr-hcj7-qf5w (hoch). Gefixt erst in 4.1.2 (Lizenzschlüssel nötig), es gibt keinen 3.x-Fix. ## Analyse (wie Checkly ImageSharp nutzt) ImageSharp wird nur in `Checkly/Uploads/ImageUploadValidator.cs` (Avatar-Upload, KI-Produktfoto-Erkennung) verwendet. - **GHSA-wmxv-xphr-5c9g (BigTIFF-Endlosschleife): erreichbar.** `Image.Identify` läuft mit der Default-Konfiguration (alle Decoder inkl. TIFF) *vor* der JPEG/PNG/WebP-Allowlist. Nachgestellt mit 3.1.12: eine 24-Byte-BigTIFF hält `Identify` > 8 s (praktisch unbegrenzt, ~2^56 Iterationen) auf einem Thread fest, nicht abbrechbar. Jeder eingeloggte Nutzer kann das über den Avatar-Upload auslösen. - GHSA-gwg2-r3hj-4w44 (ICC-CLUT): in 3.x nur über `IccProfile.Entries` erreichbar, das Checkly nie aufruft. - GHSA-j3p4-wp97-rph4 (HistogramEqualization), GHSA-j9gm-c75j-xc9q / GHSA-jjfr-hcj7-qf5w (TIFF-CCITT-Encoder): nicht erreichbar, Checkly nutzt weder HistogramEqualization noch einen TIFF-Encoder. **Zusatzbefund (Datenschutz-Bug):** Entgegen den Code-Kommentaren bleiben EXIF-Daten (inkl. GPS) beim Re-Encoding erhalten (nachgestellt: EXIF überlebt Load -> Resize -> JPEG/WebP). Avatare sind für andere Listenmitglieder sichtbar; das an den KI-Anbieter geschickte Foto enthält ebenfalls EXIF (verletzt Security-Pre-Review-Punkt 2 von #95). ## Entscheidung (Mensch, 2026-10-08) Option (c): bei 3.1.12 bleiben, Risiko mit Mitigationen akzeptieren. (Alternativen: Migration auf SkiaSharp, ImageSharp-4-Lizenz kaufen.) ## Akzeptanzkriterien - Upload-Decoding nutzt eine Konfiguration nur mit JPEG/PNG/WebP-Decodern (auch für `Identify`); eine BigTIFF-Datei wird sofort abgelehnt. - Vor dem Speichern/Weitergeben werden alle Metadaten-Profile (EXIF, XMP, ICC, IPTC) entfernt - gilt für Avatar und KI-Foto. - Die fünf Advisories werden gezielt per `NuGetAuditSuppress` mit Begründung unterdrückt (neue Advisories bleiben sichtbar). - Tests: BigTIFF wird abgelehnt (mit Timeout), EXIF ist im gespeicherten Avatar und im KI-JPEG nicht mehr enthalten.
lena self-assigned this 2026-10-08 21:47:19 +02:00
lena commented 2026-10-08 21:47:20 +02:00
Author
Collaborator
Copy link

Claimed by session "Update vulnerable ImageSharp in Checkly [33dd42]"

Umsetzung von Option (c) laut Issue-Beschreibung.

Claimed by session "Update vulnerable ImageSharp in Checkly [33dd42]" Umsetzung von Option (c) laut Issue-Beschreibung.
lena commented 2026-10-08 21:56:24 +02:00
Author
Collaborator
Copy link

Erledigt in 83aac247 (Fix) und 79ad574a (Team-Memory), direkt auf master.

Umfang (Option c)

  • ImageUploadValidator nutzt für Identify und Load eine Konfiguration, die nur JPEG-, PNG- und WebP-Decoder kennt. TIFF/BigTIFF, GIF, BMP usw. werden sofort als unbekanntes Format abgelehnt; die BigTIFF-Endlosschleife (GHSA-wmxv-xphr-5c9g) ist damit nicht mehr erreichbar.
  • Nach dem Decodieren wird die EXIF-Ausrichtung angewendet (AutoOrient, damit Handyfotos nach dem Entfernen der EXIF-Daten nicht quer liegen) und alle Metadaten-Profile (EXIF inkl. GPS, XMP, ICC, IPTC, CICP) auf Bild- und Frame-Ebene entfernt. Gilt für Avatar und KI-Foto.
  • Die fünf Advisories sind einzeln per NuGetAuditSuppress in Directory.Build.props unterdrückt, mit Begründung zur Erreichbarkeit. Neue ImageSharp-Advisories schlagen weiterhin an.

Tests

  • Neu: BigTIFF-Upload wird innerhalb von 5 s mit ArgumentException abgelehnt; gespeicherter Avatar enthält kein EXIF; das an den KI-Dienst gesendete JPEG hat kein EXIF und ist aufgerichtet (Orientation 6, 40x20 -> 20x40).
  • Lokal grün: Checkly.Tests 1202, Checkly.WebApi.Tests 68, Common.Tests 119. dotnet build ohne ImageSharp-Audit-Warnungen.

Security-Review: keine Befunde. Hinweis des Reviews zu JPEG-COM-Kommentaren geprüft: ImageSharp 3.1.12 modelliert diese nicht (JpegMetadata hat keine Comments), sie werden also nicht mit ausgegeben.

Bekannte Grenzen

  • Wir bleiben auf ImageSharp 3.1.12 ohne weitere Upstream-Fixes. Bei jeder ImageSharp-Änderung die Suppress-Liste neu prüfen; langfristig bleibt die SkiaSharp-Migration eine Option.
  • Bereits gespeicherte Avatare enthalten weiterhin ihre alten EXIF-Daten, bis der Nutzer ein neues Bild hochlädt (keine Datenmigration).
Erledigt in 83aac247 (Fix) und 79ad574a (Team-Memory), direkt auf `master`. **Umfang (Option c)** - `ImageUploadValidator` nutzt für `Identify` und `Load` eine Konfiguration, die nur JPEG-, PNG- und WebP-Decoder kennt. TIFF/BigTIFF, GIF, BMP usw. werden sofort als unbekanntes Format abgelehnt; die BigTIFF-Endlosschleife (GHSA-wmxv-xphr-5c9g) ist damit nicht mehr erreichbar. - Nach dem Decodieren wird die EXIF-Ausrichtung angewendet (`AutoOrient`, damit Handyfotos nach dem Entfernen der EXIF-Daten nicht quer liegen) und alle Metadaten-Profile (EXIF inkl. GPS, XMP, ICC, IPTC, CICP) auf Bild- und Frame-Ebene entfernt. Gilt für Avatar und KI-Foto. - Die fünf Advisories sind einzeln per `NuGetAuditSuppress` in `Directory.Build.props` unterdrückt, mit Begründung zur Erreichbarkeit. Neue ImageSharp-Advisories schlagen weiterhin an. **Tests** - Neu: BigTIFF-Upload wird innerhalb von 5 s mit `ArgumentException` abgelehnt; gespeicherter Avatar enthält kein EXIF; das an den KI-Dienst gesendete JPEG hat kein EXIF und ist aufgerichtet (Orientation 6, 40x20 -> 20x40). - Lokal grün: Checkly.Tests 1202, Checkly.WebApi.Tests 68, Common.Tests 119. `dotnet build` ohne ImageSharp-Audit-Warnungen. **Security-Review:** keine Befunde. Hinweis des Reviews zu JPEG-COM-Kommentaren geprüft: ImageSharp 3.1.12 modelliert diese nicht (`JpegMetadata` hat keine `Comments`), sie werden also nicht mit ausgegeben. **Bekannte Grenzen** - Wir bleiben auf ImageSharp 3.1.12 ohne weitere Upstream-Fixes. Bei jeder ImageSharp-Änderung die Suppress-Liste neu prüfen; langfristig bleibt die SkiaSharp-Migration eine Option. - Bereits gespeicherte Avatare enthalten weiterhin ihre alten EXIF-Daten, bis der Nutzer ein neues Bild hochlädt (keine Datenmigration).
lena closed this issue 2026-10-08 21:56:24 +02:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
feature/in-app-notifications
feature/list-archiving
feature/filter-search
No results found.
Labels
Clear labels   
priority/could

   
priority/must

   
priority/should

   
priority/wont

   
status/blocked

   
status/claimed

   
status/done-migrated

   
type/bug

   
type/feature

   
type/infra

   
type/tech-debt
No labels
priority/could
priority/must
priority/should
priority/wont
status/blocked
status/claimed
status/done-migrated
type/bug
type/feature
type/infra
type/tech-debt
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
lena
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
robert/todo#241
No description provided.