As I did on app/, finalizing an output stream also implicitly flushes
and closes it. Hence if an export ended with an error, we'd end up with
incomplete data file (possibly overwriting a previously exported image).
Only 2 plug-ins I haven't fixed yet are file-tiff-io and file-gif-save.
The later one don't even clean up its memory (which somehow is good here
as at least the output stream is never finalized hence sane files are
not overwritten in case of errors). As for the former (TIFF plug-in), it
doesn't even seem to have any error control AFAICS, apart from printing
error messages on standard error output.
Introduce GIMP_PATTERN_MAX_SIZE (10000) and GIMP_PATTERN_MAX_NAME (256)
and validate pattern dimensions and pattern name length against them.
Add GIMP_BRUSH_MAX_NAME and validate that too.
Also make sure that the names are properly terminated, and some
cleanup.
It is possible to trigger a heap overflow with insanely large GBR
files with a deprecated file format on 32 bit systems.
The problem is that old versions of GBR allowed an additional pattern
after the brush data. These patterns have always 4 bytes per pixel,
but the initial size check is performed with the bytes per pixel of
the brush, which can be different.
If the brush has 1 byte per pixel and the dimensions are sufficiently
large, this can trigger a heap overflow with attacker-controlled
amount and content of data.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
This reverts commit 06d24a79af.
The CVE is still fixed but now in a different way. Commit 4fa0cd4dcf
passes instead the accurate string length when using the string, hence
making it work even when not NUL-terminated. This has the advantage of
having the GBR file loaded in the end, despite such file format error. I
am personally not persuaded this is the best path since a file with such
an error may either be corrupted, or worse may have been constructed on
purpose to be harmful, so rejecting it directly may be the safe choice.
Nevertheless I may also be too doubtful and maybe trying to save a
slightly corrupted file may be the nicest choice indeed.
The file formats GBR and PAT contain names which are supposed to be
NUL-terminated within the files. If no such terminating NUL byte
exists, the parsers of GBR and PAT trigger an out of boundary read
during utf-8 conversion.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
...in both the core and libgimp.
Images now know what the default mode for new layers is:
- NORMAL for empty images
- NORMAL for images with any non-legacy layer
- NORMAL_LEGAVY for images with only legacy layers
This changes behavior when layers are created from the UI, but *also*
when created by plug-ins (yes there is a compat issue here):
- Most (all?) single-layer file importers now create NORMAL layers
- Screenshot, Webpage etc also create NORMAL layers
Scripts that create images from scratch (logos etc) should not be
affected because they usually have NORMAL_LEGACY hardcoded.
3rd party plug-ins and scripts will also behave old-style unless they
get ported to gimp_image_get_default_new_layer_mode().
Integer overflows allow out of boundary writes while reading GIH files.
The checks are copied from file-gbr.c. In turn, the necessary gsize
casts are added in file-gbr.c, too. These are important on 64 bit
systems. Without these casts, the precision of the calculation is still
32 bit, allowing overflows.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Try to sort all GIMP_ICON_* defines into FDO categories like in
https://specifications.freedesktop.org/icon-naming-spec/latest/ar01s04.html
Add defines for all icons we override, rename some icons to their FDO
standard names, and mark the ones we duplicate with a comment so we
don't forget to rename those to standard names in 3.0.
with proper value names. Mark most values as _BROKEN because they use
weird alpha compositing that has to die. Move GimpLayerModeEffects to
libgimpbase, deprecate it, and set it as compat enum for GimpLayerMode.
Add the GimpLayerModeEffects values as compat constants to script-fu
and pygimp.
If there is no gimp-[brush|pattern|brush-pipe]-name parasite,
default to the file's basename without extension, instead of
always "GIMP Brush" etc.
Also clean up the code, and make the plug-ins do the same things the
same way.
- use G_FILE_CREATE_NONE instead of 0
- don't put "Could not open <file> for writing: <error>" around the
returned error, the returned message is already verbose
and keep GIMP_ICON_TYPE_STOCK_ID as a deprecated alias. Change all
plug-ins accordingly and increase the pluginrc file version number so
it gets regenerated with "icon-name" instead of "stock-id".
and clean up the formatting of the call and the lines around it. Now
we can check the various (disabled) export options for regressions
again by changing a single line in gimp_export_image().
I'm sure some plug-ins need to add their items *not* at the toplevel,
but since making plug-ins really tree-aware is a lot more work than
just fixing insert positions, I went for passing -1 as parent in
almost all cases. And because of laziness...
Use 0666 as permissions instead of 0644 and let the user's umask care
about restricting, so creating a file with open() behaves the same way
as with fopen().
2009-01-17 Michael Natterer <mitch@gimp.org>
* all files with a GPL header and all COPYING files:
Change licence to GPLv3 (and to LGPLv3 for libgimp).
Cleaned up some copyright headers and regenerated the parsers in
the ImageMap plugin.
svn path=/trunk/; revision=27913
2008-12-26 Sven Neumann <sven@gimp.org>
* plug-ins/common/file-gbr.c: let the save procedure also accept
a
grayscale layer with alpha channel, as we do in the GIH save
procedure.
* plug-ins/common/file-gih.c: when loading a brush mask pipe,
create grayscale layers without an alpha channel. Changed the
save
procedure to also accept layers without alpha channel.
svn path=/trunk/; revision=27831
