gmonstart / jvregisterclasses in tons of binaries with commands,malware?
In linux binaries, in any linux distro, I've discovered the same strings which I believe may be due to a virus or trojan. Yet, clamav, rkhunter, chkrootkit do not detect abnormalities. Whether I run 'strings' on the binary files or view with vim or gedit, here is what is always seen inside the binaries: __gmon_start__ _Jv_RegisterClasses Followed by commands which differ within each binary. If, by some luck, I've downloaded a fresh Linux ISO where binaries do not include the above two strings followed by commands, after I run an update the updated binaries suddenly contain the above two strings and other, what I believe to be, rogue strings. I've avoided the possible infection with an OpenBSD install, yet all the Linux installations and burned ISOs contain binaries with the above two strings followed by commands. Search using find within your bin and sbin directories for those two strings and see how many positives you find. Now use a text editor like vi or gedit and search through the gibberish, locate these strings and isolate the commands, if any, which follow them. Searching for gmonstart, gmon, registerclasses, jv, etc. variations of works. If you find results in your binaries, please copy/paste the commands following the gmonstart and jvregisterclasses strings so I may compare them to mine. I've purchased Linux CDs from brick + mortar stores, downloaded ISOs from different physical locations and found some CDs contained these strings in the binaries and one or two rare ones did not, but when installed/updated on a network connection the binaries replaced in the update process would show these strings!! These strings are not alone by themselves in the binaries they follow with commands with a @ mark before each command. Google results are vague, some suggest shell backdoors, every Linux user I've asked to date calls me paranoid while at the same time this knowledge comes as a surprise to them, too, when they search their binaries and find the same strings. I'm amazed by how quickly some rush to judgement and call you a paranoid for being curious about the files on your system. The strings may/may not be common, but in comparing commands which follow these strings I've noticed some which seem down right malicious! Maybe they're right, I'm just paranoid, but what am I seeing and why are these strings so common across Linux distros binaries, esp. the Jv (java?) reference? Please, any help? -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: gmonstart / jvregisterclasses in tons of binaries with commands,malware?
Suspect it comes from gnu gprof. Openbsd wouldn't produce the string because it runs bsd gprof. -Fred Concklin On Dec 16, 2009 6:16 PM, whereislibertyandjust...@safe-mail.net wrote: In linux binaries, in any linux distro, I've discovered the same strings which I believe may be due to a virus or trojan. Yet, clamav, rkhunter, chkrootkit do not detect abnormalities. Whether I run 'strings' on the binary files or view with vim or gedit, here is what is always seen inside the binaries: __gmon_start__ _Jv_RegisterClasses Followed by commands which differ within each binary. If, by some luck, I've downloaded a fresh Linux ISO where binaries do not include the above two strings followed by commands, after I run an update the updated binaries suddenly contain the above two strings and other, what I believe to be, rogue strings. I've avoided the possible infection with an OpenBSD install, yet all the Linux installations and burned ISOs contain binaries with the above two strings followed by commands. Search using find within your bin and sbin directories for those two strings and see how many positives you find. Now use a text editor like vi or gedit and search through the gibberish, locate these strings and isolate the commands, if any, which follow them. Searching for gmonstart, gmon, registerclasses, jv, etc. variations of works. If you find results in your binaries, please copy/paste the commands following the gmonstart and jvregisterclasses strings so I may compare them to mine. I've purchased Linux CDs from brick + mortar stores, downloaded ISOs from different physical locations and found some CDs contained these strings in the binaries and one or two rare ones did not, but when installed/updated on a network connection the binaries replaced in the update process would show these strings!! These strings are not alone by themselves in the binaries they follow with commands with a @ mark before each command. Google results are vague, some suggest shell backdoors, every Linux user I've asked to date calls me paranoid while at the same time this knowledge comes as a surprise to them, too, when they search their binaries and find the same strings. I'm amazed by how quickly some rush to judgement and call you a paranoid for being curious about the files on your system. The strings may/may not be common, but in comparing commands which follow these strings I've noticed some which seem down right malicious! Maybe they're right, I'm just paranoid, but what am I seeing and why are these strings so common across Linux distros binaries, esp. the Jv (java?) reference? Please, any help? -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: gmonstart / jvregisterclasses in tons of binaries with commands,malware?
On Wed, Dec 16, 2009 at 05:59:13PM -0500, whereislibertyandjust...@safe-mail.net wrote: Whether I run 'strings' on the binary files or view with vim or gedit, here is what is always seen inside the binaries: __gmon_start__ _Jv_RegisterClasses They're put there by gcc and are perfectly harmless. What makes you suspicious of them in any way? If you inspect these programs or libraries with objdump, you'll see stuff like w D *UND* __gmon_start__ w D *UND* _Jv_RegisterClasses that indicates that these are weak references, meaning that they don't necessarily even do anything. The symbols are basically stubs that can optionally be filled in at linktime but don't need to be. Digging into the gcc source code, it's apparent that __gmon_start__ can be used by some profiling libraries, while _Jv_RegisterClasses has something arcane to do with calling C++ code from Java, or something like that. (Remember that the gcc suite includes a Java compiler and related tools.) You can find all the source in the gcc source tree. You may not see these symbols on OpenBSD systems because they don't include Java or gprof support in the gcc builds. That's just a guess, though. I don't know that for sure. I'm all for some healthy paranoia, but really, when faced with the possibilities oh my god, the whole world has been pwned or I must be misunderstanding something, go with the latter. noah signature.asc Description: Digital signature
Re: gmonstart / jvregisterclasses in tons of binaries with commands, malware?
Quoth whereislibertyandjust...@safe-mail.net, on 2009-12-16 17:59:13 -0500: Whether I run 'strings' on the binary files or view with vim or gedit, here is what is always seen inside the binaries: __gmon_start__ _Jv_RegisterClasses These are internal symbols generated by the compiler. __gmon_start__ is used for profiling, and _Jv_RegisterClasses is part of the GCJ Java ABI, at least based on a cursory glance at the GCC source. You might notice that an executable freshly compiled with GCC 4.3 from unstable has these symbols as weak symbols. I would hazard a guess that they're stub functions called from common startup code in case the relevant object files get linked with Java code or anything with profiling enabled (in which case the real functions would be pulled in and override the stubs). I've purchased Linux CDs from brick + mortar stores, downloaded ISOs from different physical locations and found some CDs contained these strings in the binaries and one or two rare ones did not, but when installed/updated on a network connection the binaries replaced in the update process would show these strings! In other words, most likely, you upgraded the binaries from versions compiled with an old compiler (and therefore not having the same internal symbols) to ones compiled with a new compiler. As for OpenBSD, it's entirely plausible that a different platform would port the compiler differently, or use more aggressive symbol stripping, or a slightly different C library, or any number of other things that might perturb the internal symbols, since they're not meant to be highly stable and portable. every Linux user I've asked to date calls me paranoid I'd have to agree on that one, in this regard. The strings may/may not be common, but in comparing commands which follow these strings I've noticed some which seem down right malicious! This is a pretty ill-defined statement, but I'm curious what strings exactly you've seen that make you think this. Of course, it's impossible for me to determine definitively that you don't have some _other_ hostile factor on your machine. --- Drake Wilson -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: gmonstart / jvregisterclasses in tons of binaries with commands,malware?
whereislibertyandjust...@safe-mail.net wrote: __gmon_start__ A minute with a search engine will tell you this symbol is included in the standard glibc, and is a hook into early program runtime provided by sysdeps/generic/initfini.c _Jv_RegisterClasses This is part of GCC's libgcc library, and is defined in the crtstuff.c file. http://www.google.com/codesearch/ is an easy way to find the code where symbols you are interested in originate. These strings are not alone by themselves in the binaries they follow with commands with a @ mark before each command. If you're referring to things like these: setrli...@glibc_2.0 msg...@glibc_2.0 That is library symbol versioning, a feature of linux's linker, most often used by glibc. http://people.redhat.com/drepper/symbol-versioning -- see shy jo signature.asc Description: Digital signature
