Hi,

I got some binaries from internet (amule), but am afraid of using them, exposing my system. Since some run long simulations, it is not desirable to run in slow VM.

What do you gurus say if I run it as a new user? So the binaries would just be able to read and execute my binutils... Is that harmfull?

Tks in advance

Hi,
well I'm not a guru, but it should be ok running it as new user.
cheers

0 members found this post helpful.

Running unknown executable even as regular different user can be harmful.
You kernel may be vulnerable for local root exploit, for example.

More than that, if you don't trust this binary,
how can you trust it's output ?
And if you can't what's the point of running it at all ?

While I understand most reasons LQ members will give, "not being a guru" is not a reason and those of the "I think", "I assume" or "it seems" kind even less. So please elaborate and tell us the exact reasons why you think that is OK? Details please.


Most generic documents warn users about running "untrusted" binaries. Taking a product-agnostic stance towards things the first step 0) would be to verify that binaries or the contents of the archive are authentic, as the developer intended them to be. This should be done preferably by using the developers public GnuPG key on the accompanying signature of the object. Where a GnuPG key is not available, and unfortunately this happens in too many cases still, 1) one could fall back to comparing hashes but trustworthiness of these is a magnitude less. Still a magnitude less would be to 2) 'net research to see if any vulnerabilities are listed in say the CVE (mitre.org), on regular sites like SecurityFocus or Secunia or on exploit sites or 3) if any grave problems are listed in the community like the products fora, mailing lists (archives) or elsewhere.


Letting any subjective reasoning ("my boss needs it NOW", "it seems harmless", "I think it's OK") interfere with or overrule an objective assessment is the best way to fsck things up. You're looking at two disparate things: 0) the risks and 1) seeking trade-offs. Understanding the risks means understanding in what way running binaries may be damaging to your system, a (any) network (or even your identity) and in what ways you could mitigate risks effectively.

Let's take some risks and see which way they can be traced and mitigated:
* Running an exploit. The binary contains malicious code that exploits a weakness in kernel or userland. If the exploit elevates the users rights to run commands as root user then such an event can lead to a complete compromise of the system. Tracing events means logging syscall and MAC policy violations (GRSecurity, SE Linux, LoggedFS to some extent, strace), logging network connections (iptables "-j LOG") and verifying the systems integrity (Samhain, Aide, Osiris, Integrit or even tripwire). PAX, ASLR, and MAC features may help protect a system from exploits. If run inside a VM then (chances are good that) this will only affect the guest OS and not the host. Propagating an exploit in well-known SW is rare for many reasons (the "many eyeballs" thing) but not impossible as cases of compromised SW mirrors have shown in the past.

* Opening up a (connect-back) backdoor. The binary opens up a port allowing remote hosts to connect to your system or opens up a connection to a remote host. If a remote host manages to connect to the port then the process would be run as the user. This means additional action is needed for system recon and exploiting anything. Binding to a port is bound to the Linux capabilities the unprivileged user has (meaning no port =< 1024) and not any port already in use and a favorable firewall policy. Tracing network communication between systems means logging network connections. A "default drop; allow only specific ports" firewall policy will block this traffic. A restrictive router policy may deny connections. A GRSecurity or SE Linux policy may deny a user ingress and egress traffic rights. Standard (security) tools like netstat, lsof, fuser, unhide, Tiger, Usat, Chkrootkit, Rootkit Hunter, may (help) expose a backdoor. A reactive IDS (Snort + Guardian?) may deny traffic.

* Running a sniffer. The binary runs a listening device that gathers information. If run in promiscuous mode (which only root may do) information may be learned, stored and shared that may compromise your or other systems or any aspect of your identity. Tracing sniffers, unless well-hidden, is covered by a lot of the tools mentioned before. A GRSecurity or SE Linux policy may deny a user to run processes requiring certain rights. Finding backdoors or sniffers in well-known SW again is very rare but not impossible. Running in a VM guest OS may or may not offer additional protection where sniffing in promiscuous mode is concerned depending on how it is networked.

* Running an arbitrary process or having unsolicited "features". The binary runs a process or feature unknown to the user or a standard system utility that may "phone home" for whatever reasons, infect binaries with RST-B, damage files, send bulk email, send commands to other machines, join IRC channels or simply help you into The Wrong Trousers. Rights to execute processes may be governed by for instance GRSecurity (Trusted Path Execution) or a SE Linux sandbox policy (or PolicyKit? I haven't had the time to play with it yet). Detecting and regulating network connections was handled above. Make backups ;-p Running a VM guest does not offer additional protection out of the box: any detection methods and access restrictions have to be configured beforehand. A VM may be beneficial wrt damage as you can "lock" a disk and restore contents to a previous state. Running an arbitrary process or having unsolicited "features" is a far-fetched scenario for the same reasons mentioned above. Still a nice recent (2009) one comes to mind masking itself as a nice Waterfall(?) screensaver but running a shell script instead.

In short this reply only serves to educate, not to spread FUD or damage. It isn't exhaustive but I hope it shows you that logging and auditing are important aspects to be and remain in control, that methods for detection exist, that a VM can be helpful under certain circumstances and that available methods do not necessarily have to be hard to implement: some GNU/Linux distributions already come with them enabled like SE Linux (RHEL, Fedora, Centos), GRSecurity (Gentoo) or AppArmor (SuSE, Ubuntu). One aspect I left out was (aiding) identity theft. This spans not just one level of detection or protection. If somebody wants to fill in that gap: go right ahead.


Depending on where you got it from, depending on how it can be verified to be authentic and depending on the risks you're willing to take you can run that binary from a cleanly created, unprivileged user account. However in your case the point of running unknown binaries is moot since the source-code for Amule is readily available (if not from your distributions core or a third party repo then) from the developers Sourceforge site and instructons are available here. So in your case there simply is no need to run the binary: just verify and compile yourself.

4 members found this post helpful.

Post Scriptum: I sometimes have to run potentially hostile code myself and I value my and other peoples systems and networks too much to run hostile code outside a fortified VM or Live CD. I started running VM when I still had a SMP PIII with 512MB RAM so to me "slow" is relative.

3 members found this post helpful.

Great response, unSpawn. Needless to say, it's bookmarked.

cheers,

1 members found this post helpful.

If the binary was just running just as a user, not as root, it can't get really do too much harm.

0 members found this post helpful.

Your response, just like your previous one, leads me to believe you should be posting questions, not make statements.

3 members found this post helpful.