Why does a random header file have the execute permission at /usr/include?
Impressive my friend. This is a real fruit of investigation, and it explains everything.
It only took about 3 minutes between reading your post to figuring it out, but that's because
- I knew that Arch's packages were on their Gitlab
- I knew to look for
url=in the PKGBUILD - I knew
installdefaulted to 755.
And now, we know those things too.
Thanks, u/OneTurnMore! I'm smarter today because of you!
I knew none of these.
now you know all of these
Thank you!
I see you're a civ player.
I'm in recovery, it's been at least a year since I clicked one more turn after midnight
How did you even catch that
He’s trying to be the next Microsoft engineer that spot the xz exploit
Whilst execute permission missing by default on files downloaded from the Internet probably is a huge win for GNU/Linux security compared to Windows (or even OS X which made installing apps way too easy till recently), it is really easy to bypass execute permission missing if you were say a rogue package maintainer.
I'm a big fan of minimal permissions, but UNIX and Linux have been a disappointment in this regard. HP-UX used to ship the permissions on the box used to create the packages, which were usually good and occasionally rubbish.
If I were going to "audit" it, I'd probably start with find /usr/ -type f -executable -iname '*\.*' -regextype posix-egrep ! -regex '.*\.(csh|sh|py|so|pl|exe|dll|cgi|lua).*' | egrep -v '^/usr/s?bin/' before I did any deep analysis.
Which points out /usr/share/audacious/Skins/Debian/nums_ex.bmp on my system, heh.
Don't underestimate the curiosity of Linux users! After what Andres Freund did, I think it's the least impressive.
the same way the xz library exploit was detected
Ask the package maintainer.
How do I get icons for my ls command too?
Not OP but it might be Eza, a Rust version of ls. Previously called Exa
Yeah, that's eza, you are right. I think it's really awesome. The numbers in front of each entry are inodes and you can print them with the --inode option.
Agreed, I have it aliased to ls. I don't know what inodes are though tbh - just a vague intuition about disk space allocation, I suppose.
Inodes are essentially numbers that point to the file metadata. Filesystems store metadata about the file like its name, owner, permissions, size and timestamp in separate inode table and each file is associated with inode to get its metadata. Inodes can be accessed through the stat syscall/CLI.
Newbie here. What can you do with the inodes information?
Not really much, I'm just curious and that's it. It's more of a programming thing than a user. The stst command can, among other things, show when a file was created, modified, accessed, its size, etc.
There's also lsd, it just more fun to use.
It also supports tree depth (lsd --tree --depth 3 if you want to see what it does)
Thanks! I'll look it up.
Also one important note is that you need a terminal font that has those icons, FiraCode is one popular option.
I use lsd to do this
EDIT: I wrote this a couple of hours ago and then forgot to press "save", so by the time I actually posted, it had already been discovered that this is a bug in the upstream Makefile (EDIT 2: my first edit incorrectly blamed the packager rather than the upstream authors - I should have read more carefully). I'll leave this comment up because I believe the note at the beginning is important.
I don't want to alarm you too much with this comment, and I do think it's possible that this is just a packaging error. But, with that out of the way...
A couple of comments in this thread have stated that it doesn't particularly matter that this is +x, since you can't actually execute a C header anyway.
I wish to state my strong disagreement with that line of thought. It is a potentially dangerous mistake to assume that a file's name is an honest representation of its contents. A shell script, an ELF binary, or any other type of data can be given a name ending in .h. Even if this particular example turns out to be innocent, this ought to be noted for anybody ending up here from a search engine in the future.
It's not uncommon for malware (typically cryptominers, these days) to be given a name that make it look like it's a normal part of the system. There have been a few posts here, over the past year or so, where it's been clear that that has happened. Admittedly, the examples I've seen have been owned by either the user that was tricked in to installing it or the service that was exploited, rather than installed in a way that implies root access, and they've been given filenames intended to be inconspicuous in a list of running process, rather than in a directory listing. However, I think this is still something that should be investigated.
(Apart from anything else, it's pretty easy for a process to change the way it appears in top. I haven't seen this so far, because cryptominers are generally deployed with the very lazy camouflage of simply renaming a binary that wasn't even designed to run without the machine owner's knowledge. Having one name that blends in on the filesystem and another that blends in on the process list would be an entirely reasonable first step to take if one was designing a less lazy payload.)
I would start by investigating it with the file command, which will readily identify if it's a binary. However, I wouldn't trust the answer completely - I would also like to skim the file in a text editor. (This shouldn't take long: the real thing is only about 450 lines, and one doesn't need to actually read and understand the code to check that it legitimately looks like a C header.)
The reason I don't want to trust file here is that I do not know exactly how it identifies C source code (if anybody does feel like interpreting some magic, here it is). However, given that valid C preprocessor directives are also valid comment lines in a shell script, I wouldn't like to bet that it can't be spoofed. Again, this is pure speculation about what a malware author might choose to do, but it seems possible, to me, that it would be a surprisingly simple trick to pull off.
Apart from a malicious program deliberately concealed on your system, the other major possibilities that occur to me are:
Filesystem corruption. Seems unlikely that this would be the first issue you'd notice, but who knows.
User error. I can't immediately see how to make a
chmodtypo that affect this file in particular, but I could see somebody doing this as a desperate attempt to debug a failing build.Package maintainer error.
Regarding that last possibility, it would be useful here to know which distribution you're using. If this also affects other people's systems, it should be reported upstream to avoid worrying anybody else.
Also, it may be possible to check if the package that provides that file is actually installed, and even check if its contents match those provided by the package, but the relevant commands depend on your package manager.
On my Debian Unstable system, /usr/include/http_parser.h is part of the package libhttp-parser-dev. I installed it just to check, and, as expected, it is not executable. In fact, find /usr/include/ -executable -type f produces zero results. (I can't see why it should ever show results, but of course I do not have every -dev package installed.)
Yeah, we found out that it was because the install command was giving files the execute permission, in which case it makes more sense to simply move files to /usr/include, but you are right this is a potential attack surface you should be careful about. Interestingly enough, your command to find executable headers actually produced one more result:
[chocolate-magnate@millenium ~]$ find /usr/include/ -executable -type f
/usr/include/http_parser.h
/usr/include/glibmm-2.68/glibmm/environ.h
And the /usr/include/glibmm-2.68/glibmm/environ.h file starts with:
#ifndef _GLIBMM_ENVIRON_H
#define _GLIBMM_ENVIRON_H
/* Copyright (C) 2021 The glibmm Development Team
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
*/
#include <glibmm/ustring.h>
#include <memory>
#include <optional>
#include <string>
#include <vector>
namespace Glib
{
/** A convenience class for manipulating a copy of the environment variables.
*
* Useful for generating the u/a envp parameter in calls to
* Glib::spawn_async_with_pipes(), Glib::spawn_async() and Glib::spawn_sync().
*
* If you want to change the environment itself (i.e. not a copy of it),
* see Glib::getenv(), Glib::setenv() and Glib::unsetenv().
*
I believe this project also used the install command because the header file is completely legit. Regarding my distribution, I use Gentoo Linux.
What does head /usr/include/http_parser.h return? Is it binary? Does it look like a C header file?
It's probably a mistake, but what are you worried about? It's not likely to actually be executable.
Of course its not safe if you try to execute something that may or may not be executable
Because the upstream source uses install to copy the file to the target directory.
The default mode is ‘u=rwx,go=rx,a-s’
https://www.gnu.org/software/coreutils/manual/html_node/install-invocation.html
[EDIT] I should have read the comments first, because someone already found this.
That's it, you've been backdoored your life is over
Was that file extracted from a zip file, or from some other non-posix package format?
What shell and terminal and color scheme are you using?
It's fish shell and the Kitty terminal and the Catppuccin-Mocha theme. Kitty has theme changing capabilities built-in using the kitten themes command where you can browse, preview and change them. I think it's the peak terminal ricing. Also to get icons, you will need to use a terminal font that has them, I use FiraCode.
Backdoor, maybe?
Okay I think just like how u/brimston3- said, it's most likely a mistake. The header file is a normal C file and it doesn't have any weird shebangs, so it was likely given this permission as an error in the build process. Unfortunately, though, I don't really know from which package it originates, so I think I could just remove said permission and call it a day.
Here is an expert from the beginning of the file:
/* Copyright Joyent, Inc. and other Node contributors. All rights reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to
* deal in the Software without restriction, including without limitation the
* rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
* sell copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
* IN THE SOFTWARE.
*/
#ifndef http_parser_h
#define http_parser_h
#ifdef __cplusplus
extern "C" {
#endif
/* Also update SONAME in the Makefile whenever you change these. */
#define HTTP_PARSER_VERSION_MAJOR 2
#define HTTP_PARSER_VERSION_MINOR 9
#define HTTP_PARSER_VERSION_PATCH 4
#include <stddef.h>
#if defined(_WIN32) && !defined(__MINGW32__) && \
(!defined(_MSC_VER) || _MSC_VER<1600) && !defined(__WINE__)
#include <BaseTsd.h>
Your package manager could/should know to which package this file belongs. Even though I don't know the commands this can be checked
On arch it's pacman -F $file. You do have to pacman -Fy first though
Using "apt-file search" I've found its from package libhttp-parser-dev .
it isn't compiled I dont think it can do anything
A package maintainer could very easily include a compromised init service or timer to trigger a run in bash or python. All it would need to do is execute bash source /path/to/file.h
Well since it is a header file i can definitely read it
Literally unusable
Tracing back through
pacman -F /usr/include/http_parser.h-> https://gitlab.archlinux.org/archlinux/packaging/packages/http-parser/-/blob/main/PKGBUILD -> https://github.com/nodejs/http-parser, I see the culprit in the Makefile:installis begin run without-m 644, so it defaults to755.