Peter Wolf via luv-beginners wrote:
I have found numerous files being added to my /usr/bin folder. I want to know if one of them,a perl script is malware. I strongly suspect that it is malware. Unfortunately, I don't know enough about perl to be able to tell for sure. The script doesn't seem to work properly and seems to hang the perl interperetor. Be very careful running it. I will embed it at the bottom of this email. If it is malware and something new, please forward it to the relevant people. Thanks. The filename on my hard drive is function_grep.pl
On Debian and derivatives (inc. Ubuntu) you can use "dpkg -S" to find out what package provided a file, e.g. bash5$ dpkg -S /usr/bin/broadwayd libgtk-3-bin: /usr/bin/broadwayd This doesn't always work (if the file is created dynamically), e.g. bash5$ dpkg -S /etc/alternatives/editor dpkg-query: no path found matching pattern /etc/alternatives/editor You can do the same search for files *not* installed using "apt-file search", e.g. bash5$ apt-file search xml_grep xml-twig-tools: /usr/bin/xml_grep xml-twig-tools: /usr/share/man/man1/xml_grep.1p.gz
The script doesn't seem to work properly and seems to hang the perl interperetor.
This is probably because it expects to read a file from stdin. It didn't hang, it just waited until input had finished. An example of such a program is cksum(1). bash5$ cksum <did it hang???> <cancel with Ctrl + C> bash5$ echo hello world > test.txt bash5$ cksum < test.txt 3733384285 12 If you find a file in /usr/bin and don't know what it is, USUALLY there is a manpage explaining it. For example, "man cksum". Often Debian will provide a "stub" manpage if the original software does not.
If it is malware and something new, please forward it to the relevant people.
FYI the main place to report new security issues is the "OSS sec" mailing list. https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures https://en.wikipedia.org/wiki/Responsible_disclosure Normally you would need a bit more details than "I found this bad file on my computer" before writing a report. An typical example is this email: https://seclists.org/oss-sec/2020/q4/1 I read oss-sec via nntp://gwene.io -- I'm not sure what the canonical HTTP location is, but that is *a* http view. If you want to learn more about vulnerabilities, this is a good technical overview: https://cwe.mitre.org/top25/archive/2020/2020_cwe_top25.html In terms of what you, personally, can practically do, step #1 is "threat modelling". I don't have a good introduction for that, so here is the Wikipedia article: https://en.wikipedia.org/wiki/Threat_modelling