Vulnerability scanner for Linux and FreeBSD | Hacker News Reader

Vulnerability scanner for Linux and FreeBSD

github.com

113 pointssnehesht39 comments

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.

Spacewalk is monolithic. It takes over packaging and licensing and various other roles.

I appreciate tools like this because they are single purpose and can be easily be retrofitted to old systems.

Also, yum security plugin does not work on centos because security errata are not published in repo. So you have to hack it even with spacewalk.

This tool definitely meets a need in the EL ecosystem.

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."

No thank you.

Alternatively - pam_ssh_agent_auth

I was complaining more about the sudo part. Probably should have just had that in the quote.

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.

But the part I'm concerned about is that they seem to think that having password-less sudo is a security win.

I thought they were saying they don't want people's passwords. People reuse them, naive people giving up an actual root password, etc.

Not sure they mean always using NOPASSWORD is good for security.

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.

Yes, and yes.

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.

An ssh key for root is simpler and safer.

"What does God want with a starship?"

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).

SUDO with Password via ssh is technologically possible.

http://askubuntu.com/questions/470383/how-to-avoid-prompt-pa...

But there is a problem with sudo with password via ssh.

For example...

  userA .... 'watch w' on serverA
  userB ... 'ssh serverA echo sudopassword | sudo -S command'

userA can steal of root password on ServerA because plain sudo password is displayed by w command.

So, I disable -ask-sudo-password for security reasons. https://github.com/future-architect/vuls/pull/148

I recommend to define minimum commands in /etc/sudoers on target servers.

  CentOS, RHEL
    vuls ALL=(root) NOPASSWD: /usr/bin/yum, /bin/echo

  Ubuntu, Debian
    vuls ALL=(root) NOPASSWD: /usr/bin/apt-get, /usr/bin/apt-cache

 Vuls can scan without root on FreeBSD and Amazon Linux.

    // install aptitude
    cmd = util.PrependProxyEnv("apt-get install --force-yes -y aptitude")

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.

I see. I will improve.

Excellent. Don't take the comments here too much to heart. Off the top of my head, a couple of things you could look at:

* Don't use root where you don't need to - can you parse package lists / vulnerability databases as a normal user?

* Would the design be better inverted? Systems push their list of installed packages / versions to your application to be checked.

Thanks :)

> * 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.

  locales            2.13+git20120306-21  
  login              1:4.1.5.1-1.1ubuntu7  
  lsb-base           9.20160110
  make               4.1-6
  mawk               1.3.3-17ubuntu2
  mime-support       3.59ubuntu1
  multiarch-support  2.21-0ubuntu5

Impossible!!

But how is the command you mention getting that information? Couldn't you parse the package database in the same way?

Vuls parse the changelog of upgradable packages on Ubuntu, Debian, CentOS.

For details, see the flow chart in Scanning Flow section. https://github.com/future-architect/vuls#scanning-flow

Fixed https://github.com/future-architect/vuls/pull/219

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?

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.

Hypothetically, yes.

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.

How does this compare with, e.g., `pkg audit` for FreeBSD? https://www.freebsd.org/doc/handbook/security-pkg.html

https://github.com/future-architect/vuls/blob/master/scan/fr...

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.

>NVD is just used for adding details of the CVEs that has been found.

yes.

Vuls issues below command.

  FreeBSD ... pkg audit -F
  RHEL ... yum plugin security
  Amazon LInux ... yum plugin security
  CentOS ... analyze changelogs
  Debian ... analyze changelogs
  Ubuntu ... analyze changelogs

VulsRepo is visualized based on the json report output in Vuls. https://github.com/usiusi360/vulsrepo

It is useful to analyze vulnerabilities that are detected by Vuls.

Spring for Nessus if you're looking for a solid vulnerability scanner.

Use `pkg audit` on FreeBSD and read the "periodic" emails.

Or run pkg audit -F (with a nice random sleep) from your monitoring system.

FreeBSD's pkg command is awesome.

Vuls issues pkg audit -F and parse the results, and then send notification via slack or email with some additionarl informaiton ( NVD data )

See debsecan for Debian

https://packages.debian.org/jessie/debsecan

Reply on news.ycombinator.com