1. 34
  1. 14

    A logo vulnerability for a local exploit without privsec for a software with a small market share, running on a system with an even smaller market share. I’m always interested about writeups, but I doubt the landing/marketing page was required.

    1. 14

      Yes but think about context: they’re working with GIMP. 😜

      1. 1

        I think I’m missing the joke here.

        1. 3

          I think the joke is that since the vulnerability is in an image editor, that of course they had to make a logo for the vulnerability using the image editor.

      2. 5

        I think being picky about the distinction between “logo deserving vuln” and “just a CSVCVE [1]” is silly, because whatever we were doing before to communicate security issues and get end users to pay attention wasn’t working at all. I don’t know if this is better, but at least it’s different.

        [1]: I am currently working on a CSV issue… blah

        1. 4

          Its worth noting that the page says that no one from the Gimp team seems to take them seriously. The publicity that this site will get might help that change.

          1. 1

            Did you see what @hanno responded to this on twitter?

            There were some comments criticizing me for making such a buzz about FLIMP. But one day later we have default HTTPS downloads for GIMP and people start working on merging patches & fixing stuff. It worked.

          2. 6

            It’s nice to see that this vulnerability is fully mitigated in HardenedBSD with:

            1. PaX ASLR
            2. PaX NOEXEC
            3. PIE
            4. RELRO + BIND_NOW
            1. 4

              Asking as someone does not actively following FreeBSD anymore: why doesn’t FreeBSD have ASLR or use these changes from HardenedBSD?

              1. 2

                That’s a tough question, but I think it boils down to different priorities of FreeBSD developers and clashing personalities. I’m @lattera can speak about that.

                1. 2

                  You’ll need to ask FreeBSD that question. I cannot and do not speak on their behalf.

              2. 3

                Nice work on the part of the team that found this. It’s a shame that even with details and patches being supplied, the GIMP core team doesn’t seem interested in addressing it.

                1. 3

                  lots of odd legacy parsers written by volunteers that aren’t subject to a lot of scrutiny and aren’t mitigated by any kind of modern security architecture

                  What could possibly go wrong? :D

                  1. 3

                    TBH, I don’t see the urgent need to fix this. It’s a bug, but it’s not a bug real users are going to hit in real life, and it’s hard to imagine scenarios where it could be maliciously exploited. It makes sense to me that it’s low priority for the Gimp devs.

                    On a side note, I don’t like this type of online bullying. “This project dared to disagree with me, so I’m going to blow this issue out of proportion on social media to force them to do what I want…”

                    If he thinks it’s that big of a problem he should submit a patch.

                    1. 4

                      Didn’t the site say that several of these bugs already had patches that had been sitting unapplied for ages?

                      1. 2

                        “This project dared to disagree with me, so I’m going to blow this issue out of proportion on social media to force them to do what I want…”

                        I don’t think that’s what’s going on. It’s them expressing frustration that a genuine security exploit (even a relatively minor one) - one which they have made patches for - has been glossed over for three years. There’s not been disagreement from the GIMP team, it’s just been… silence. Nothing from them. For three years. That’s a little ridiculous in my opinion.

                      2. 2

                        So, if you are using FreeBSD, and Gimp, and working with FLIC files, and are dumb enough to either run something random from the net, or let a bad person access your machine with such a file… you’re in trouble.

                        Somehow I think the union of these sets is in the low 10s, if that.

                        But hey, this gets attention for the project, and the logo is kinda cute!

                        1. 9

                          dumb enough to either run something random from the net

                          You literally opened a file from the net to write that. It’s not dumb, users should never be blamed for using files, it’s that’s what they do all the time.

                          1. 1

                            By “dumb”, I mean someone blindly loading a file they got from someone saying “hey d00d check out this cool FLIC!!!”. It’s of course entirely possible for a malicious actor to trick even a vigilant user to load a file by social engineering, MiTM attacks, or spoofing in general.

                            My point is that the attack surface for this particular vulnerability is very small.

                            I’m all for better security for all users, and the techniques the project are using seem to bearing fruit. But it doesn’t detract from the fact that this issue is relatively less serious than other issues.

                          2. 2

                            Yeah — I use FreeBSD, sometimes GIMP (but more often Krita), occasionally with files from the internet…

                            but I have NOT even heard of FLIC before