TL;DR "Give a single machine root access across your entire enterprise so you don't have to manually check each machine for security updates in the vendor-supplied packages"
Instead of dealing with this thing, I suggest looking at some existing system management tools like Landscape for Ubuntu or Spacewalk for CentOS/RHEL to handle managed updates... or learning how to set up a cron job to email you when security updates are available.
Also, it means that one machine is going to have to be ssh'ing into every server that you have on a constant basis, which creates load on that centralized server doing computational part of the ssh connection setup and tear down and all the encryption and hmac'ing. And ssh is not designed to be a lightweight protocol, and it would be simply awful to try to maintain persistent authenticated ssh connections from the management host to every server being monitored.
Really "agentless" is all a lie. The "agent" in most cases is usually sshd and you can really do better.
Also for this kind of software it makes sense to simply leverage the underlying configuration management system the admin is using. If they're using chef/puppet/cfengine they push out the client over the top of an agent-based protocol. If they're using ansible or salt they'll deploy it "agentless"-ly.
They've actually done more work to support this root-trust remote management model when they could have simplified the problem domain to just running their code (as an agent) and reporting on the one host its running on.
It seems to have been developed to tick off a buzzword ("agentless") which could have been avoided altogether.
"Vuls doesn't support SSH password authentication. So you have to use SSH key-based authentication.
And also, SUDO with password is not supported for security reasons. So you have to define NOPASSWORD in /etc/sudoers on target servers."
NOPASSWORD is pretty sane for remote access, my objection would be to any sudo escalation at all on the target.
> What Vuls Doesn't Do
>
> Vuls doesn't update the vulnerable packages.
...ok, so please just stick to stuff like unprivileged sha1sum/dpkg/rpm/stat etc.
If vuls absolutely needs some superuser privilege, it makes sense to grant some limited privs via setcap bits (though this would mean it would probably lose the "agentless" feature).
I think you misunderstood Perixoog's comment. Sudo uses PAM to ask for the password. pam_ssh_agent_auth is a PAM module that uses ssh-agent authentication instead of a password. Perixoog is saying that instead of setting NOPASSWORD, you could configure pam_ssh_agent in /etc/pam.d/sudo, and have it use the pre-existing SSH authentication as the "password", instead of having it prompt for a password.
But the part I'm concerned about is that they seem to think that having password-less sudo is a security win.
The pam module requires you to forward a remote connection to your ssh agent - when you connect to a compromised server your attacker can authenticate to other machines as you.
Sure, giving the password to an application is a mess. Because if the application is compromised, the attacker now has the application's sudo password (ie, the vuls user's password, not the root password), and that's a bad deal. But just having it NOPASSWORD wide open is strictly worse. A knee-jerk reaction is to avoid passwords because it's another attack surface that can be broken open, but in this case just getting rid of it is strictly worse. With SSH, disabling password auth is turning the locked door into a solid brick wall. With this, NOPASSWORD is taking the door off the hinges because you are afraid of someone picking it.
I really don't like saying bad things about someone's project, but a "scanner" really really really shouldn't be making configuration changes to boxes, especially without prompting.
> * Don't use root where you don't need to - can you parse package lists / vulnerability databases as a normal user?
Yes, Vuls can scan without root on FreeBSD and Amazon Linux. If you know how to scan without root on CentOS, Debian, RHEL, Ubuntu, please let me know. I also do'nt want to use root.
> * Would the design be better inverted? Systems push their list of installed packages / versions to your application to be checked.
Not so easy.
The package version, release name is not semantic versioning format.This is a output of show package versions command on Ubuntu.
Anyone know of good resources for securing USB and disk firmware? I've found the CCC presentations rather enlightening, as well as Andrew Huang's amazing work, but still feel like we live in the dark ages with respect to hardware security.
presumably an OS-level mitigation could intercept (some) attempts to write to drive firmwares, but I'm not aware of any actual implementations. it's a very ugly situation.
Hypothetical question:
If all these OS software was written in a memory safe language like say rust, would it be possible to get rid of these 'off by two' and 'out of bounds' error completely making the world a better place?
But please don't think of Rust (or anything else) as a silver bullet. If you are doing systems programming you are going to deal with unsafe code somewhat frequently. And, by not being exposed to this kind of programming often enough, it's possible that more errors will slip through the cracks.
Then there's a whole class of errors that cannot be prevented by memory safe languages. They cannot prevent crappy practices.
While true, it is quite different have to worry about lets say 10% of the code easy tracked down by unsafe blocks, or every time a string, array, memory allocation, numeric manipulation is performed.
Hypothetically you could get rid of them in any language. And hypothetically you could introduce new bugs and vulnerabilities by rewriting the code in a new language.
While Rust does solve some of the problems that C++ creates, there's no substitute for good programming and thorough testing.
Yeah but with a language that prevents memory errors wont this be avoided by default? I'm thinking that developer effort would be put into making other features or fixing bugs. Right?
That is naive. Yes, trivial out of bounds memory errors can be prevented, but no language can prevent (accidental) resource leakage which opens up for other vulnerabilities. Besides, most modern languages are written in C/C++ anyway so you have to trust the language implementors to write perfect memory unsafe code which of course they can't.
> Besides, most modern languages are written in C/C++ anyway so you have to trust the language implementors to write perfect memory unsafe code which of course they can't.
That happens to be more a factor of not wanting to rebuild everything from scratch than anything else.
Go reference implementation is fully bootstrapped in Go.
D guys a few months ago ported their frontend to D.
C#, VB.NET and F# compilers are botstrapped nowadays. With .NET Native, maybe some other parts could eventually be re-written.
The OpenJDK gets less C++ with each release and there is the plan that when AOT lands, they will slowly migrate other parts to Java as well.
Of course trying to write an optimizer from scratch that beats LLVM or GCC backends is an herculean task, hence why most projects happen to use them as backends.
If you're running FreeBSD, I would recommend not giving SSH access to a third party tool for running something that Charlie Root is e-mailing you about daily anyway.
Freebsd doc says that their database is maintained by their developers. Vuln page shows it takes data from nvd. I haven't looked into the details, but a rough guess would be that pkg-audit is better is it's really kept up to date. Nvd's version patterns have lots of issues in my experience and often need manual verification.
If I understand the diagram in the README right, this one is no different. It just analyzes changelogs of not-yet-updated packages, which are in turn prepared by distribution maintainers. NVD is just used for adding details of the CVEs that has been found.
Instead of dealing with this thing, I suggest looking at some existing system management tools like Landscape for Ubuntu or Spacewalk for CentOS/RHEL to handle managed updates... or learning how to set up a cron job to email you when security updates are available.