bug#38422: .png files in /gnu/store with executable permissions (555)

[Bengt Richter <bokr@bokr.com>]

Hi Mark.

On +2019-11-29 07:20:41 -0500, Mark H Weaver wrote:
> Hi Bengt,
> 
> Bengt Richter <bokr@bokr.com> wrote:
> > I was wanting to check on some executable files in the store,
> > and happened to see some executable .png files ;-/
> > 
> > I suspect they came in when I was playing with icecat
> > and let it load  a "theme", but I am not sure some didn't
> > also happen trying to get firefox radio buttons to work ;-/
> 
> Certainly not.  Unless you ran icecat as root, it would not have
> sufficient permissions to modify /gnu/store.  Installing a theme or
> addon in IceCat, or changing its configuration, modifies files in your
> ~/.mozilla, not /gnu/store.
>
Yes, d'oh ;-) I was writing the "PS." in my reply to Ricardo probably
while you were writing this :) There I extracted some
guix build -S tarball content and showed that that was the perm source.

> > Anyway, does anyone else get 555 permissions on files like these?
> > These are all *.png files with 555 permissons, but I trimmed back to see common prefixes.
> > Obviously the moka-con-theme was most of it, but also faba and docbook look iffy.
> 
> I looked at docbook-xsl-1.79.1, since I happen to have it installed on
> my system.  Some of the *.png files are incorrectly given executable
> permissions within the upstream source tarball itself.  I guess it's
> probably the same issue with moka-icon-theme and faba-icon-theme, since
> I don't see anything in our package code that would have done it.
Yes, I found the bad perms in the tarball likewise.

> 
> Most of the entries in your list that end with "png" but not ".png" are
> actually programs whose name ends with "png", so they *should* be
> executable.  The files in /gnu/store/.links that end with "png" are just
> random chance, because the file names themselves are hashes.
Yeah, I realized. Could have done a cleaner job, but I was also curious
how many legit executables ended in png.

> 
> > Is this zero-day stuff with a nasty somewhere, waiting for referencing
> > by another nasty, or am I being paranoid?
> 
> I think you're being paranoid in this case.  I don't see anything here
> to be concerned about, just some minor sloppiness by 3 upstreams.
>
IIRC I did read of jpeg images being used to obfuscate call-home info
in some tricky malware, so anomalies in the same kind of file triggered
the question of whether it could be accidentally on purpose ;-/

> > What is the safe way to detoxify this mess?
> 
> The proper solution is to send bug reports to the upstream developers of
> docbook-xsl, faba-icon-theme, and moka-icon-theme, asking them to fix
> the permissions of the *.png files in their source tarballs.
>
That I haven't done. Is there a standard way to do it?
"guix show moka-icon-theme" tells me homepage, but it would be nice
to have a guix show --verbose that would show bug reporting info :)

> > I know I shouldn't directly chmod anything in store, right?
> 
> Right, *never* modify files in /gnu/store directly.
> 
> > The icecat discussion got moved to mozilla,
> 
> Which discussion are you referring to?
> 

Sorry, wrong zilla ;-p

https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00686.html

>      Thanks,
>        Mark

-- 
Regards,
Bengt Richter