PCBSD 9 KDE Desktop

If you’re new to FreeBSD and PC-BSD, you might not yet be aware of all their package manager’s many commands. Nobody expects you to, at least not initially.

Pkg is that package manager and one of the its many commands I think you should get to know asap is the audit command. It’s used to audit installed packages against known vulnerabilities. I could be wrong, but I don’t think your favorite Linux distribution’s package manager has an equivalent command.

The command is very simple. Just pass the -F flag to pkg audit and it will output installed packages with outstanding vulnerabilities. By running pkg audit -F on a fresh installation of PC-BSD 10.1 KDE, for example, it reported the following vulnerable packages.

Fetching vuln.xml.bz2: 100%  458 KB 469.5k/s    00:01    
dbus-1.8.8 is vulnerable:
dbus -- incomplete fix for CVE-2014-3636 part A
CVE: CVE-2014-7824
WWW: http://portaudit.FreeBSD.org/c1930f45-6982-11e4-80e1-bcaec565249c.html

kde-runtime-4.14.2 is vulnerable:
kwebkitpart, kde-runtime -- insufficient input validation
CVE: CVE-2014-8600
WWW: http://portaudit.FreeBSD.org/890b6b22-70fa-11e4-91ae-5453ed2e2b49.html

kde-workspace-4.11.13 is vulnerable:
kde-workspace -- privilege escalation
CVE: CVE-2014-8651
WWW: http://portaudit.FreeBSD.org/dafa13a8-6e9b-11e4-8ef7-5453ed2e2b49.html

libssh-0.6.1_1 is vulnerable:
libssh -- PRNG state reuse on forking servers
CVE: CVE-2014-0017
WWW: http://portaudit.FreeBSD.org/f8c88d50-5fb3-11e4-81bd-5453ed2e2b49.html

wget-1.15_2 is vulnerable:
wget -- path traversal vulnerability in recursive FTP mode
CVE: CVE-2014-4877
WWW: http://portaudit.FreeBSD.org/ee7b4f9d-66c8-11e4-9ae1-e8e0b722a85e.html

5 problem(s) in the installed packages found.

For each vulnerable package, it points you to a Web resources for more information. Visiting the link for libssh-0.6.1_1 vulnerability, gave the following information:

Aris Adamantiadis reported the following to us:

I have found a vulnerability in stunnel (fork mode) and libssh server (if implemented with fork) that is similar to problems found in postgresql [1]. When accepting a new connection, the server forks and the child process handles the request. The RAND_bytes() function of openssl doesn’t reset its state after the fork, but simply adds the current process id (getpid) to the PRNG state, which is not guaranteed to be unique.

stunnel uses libssl, which also seeds the PRNG with the output of time(NULL), which means that vulnerability has to be exploited under a second. I have exploit code that can reproduce the issue on OpenBSD 5.4 (thanks to random PIDs) but I think it may be exploitable on other unix systems as well.

The following CVEs have been assigned:

CVE-2014-0016 stunnel PRNG vulnerability
CVE-2014-0017 libssh PRNG vulnerability

Mitigations implemented into openssl-0.9.8j (2009) makes the vulnerability not exploitable in stock openssl. The signing code for ECDSA and DSA explicitly seeds the pool with the digest to sign.

Even if your technical understanding of the vulnerability is nothing to rave about, at least you’re informed. The same command run on a new installation of PC-BSD 10.1.1 Cinnamon returned this output:

chromium-39.0.2171.95_3 is vulnerable:
chromium -- multiple vulnerabilities
CVE: CVE-2015-1205
CVE: CVE-2014-7948
CVE: CVE-2014-7947
CVE: CVE-2014-7946
CVE: CVE-2014-7945
CVE: CVE-2014-7944
CVE: CVE-2014-7943
CVE: CVE-2014-7942
CVE: CVE-2014-7941
CVE: CVE-2014-7940
CVE: CVE-2014-7939
CVE: CVE-2014-7938
CVE: CVE-2014-7937
CVE: CVE-2014-7936
CVE: CVE-2014-7935
CVE: CVE-2014-7934
CVE: CVE-2014-7933
CVE: CVE-2014-7932
CVE: CVE-2014-7931
CVE: CVE-2014-7930
CVE: CVE-2014-7929
CVE: CVE-2014-7928
CVE: CVE-2014-7927
CVE: CVE-2014-7926
CVE: CVE-2014-7925
CVE: CVE-2014-7924
CVE: CVE-2014-7923
WWW: http://vuxml.FreeBSD.org/freebsd/e30e0c99-a1b7-11e4-b85c-00262d5ed8ee.html

chromium-39.0.2171.95_3 is vulnerable:
chromium -- multiple vulnerabilities
CVE: CVE-2015-1212
CVE: CVE-2015-1211
CVE: CVE-2015-1210
CVE: CVE-2015-1209
WWW: http://vuxml.FreeBSD.org/freebsd/a6eb239f-adbe-11e4-9fce-080027593b9a.html

linux-c6-openssl-1.0.1e_2 is vulnerable:
OpenSSL -- multiple vulnerabilities
CVE: CVE-2015-0206
CVE: CVE-2015-0205
CVE: CVE-2015-0204
CVE: CVE-2014-8275
CVE: CVE-2014-3572
CVE: CVE-2014-3571
CVE: CVE-2014-3570
CVE: CVE-2014-3569
WWW: http://vuxml.FreeBSD.org/freebsd/4e536c14-9791-11e4-977d-d050992ecde8.html

2 problem(s) in the installed packages found.

Again, you’re given links for each vulnerability. If you run a FreeBSD Cloud server, that is one command you want to be running often. For the record, I ran it on my FreeBSD 10.1 DigitalOcean server and it reported zero vulnerable packages. I can rest easy, until the next audit.

Related Post:  How to install PC-BSD on an encrypted ZFS file system


Share on facebook
Share on twitter
Share on pinterest
Share on linkedin

Hola! Did you notice that LinuxBSDos.com no longer runs network ads?  Yep, no more ads from the usual suspects that track you across the Internet.  But since  I still need to pay to keep the site running, feel free to make a small donation by PayPal.

Subscribe for updates. Trust me, no spam!

Mailchimp Signup Form

Sponsored links

1. Attend Algorithm Conference, a top AI and ML event for 2020.
2. Reasons to use control panel for your server.
3. DHgate Computers Electronics, Cell Phones & more.

29 Responses

  1. You said: “Encryption of the root partition is not supported. While it is possible to specify the encryption of the other partitions, the implementation does not provide the protection that disk encryption is expected to. Fedora has a better implementation of disk encryption than this or any other distribution.”

    This is a very dumb thing to say for the following reasons:

    1) Slackware was the first real distribution to be able to encrypt its root partition (starting with 12.0 released June 2007) and this was documented BY Slackware and released as a README_CRYPT.TXT on the official install media. The first time Fedora was able to be installed this way that I see on Google is Fedora 8, November 2007.

    2) Such a setup on Slackware Linux is extremely easy (just manually create LUKS+LVM, tell setup to install to it, make an initrd, and reboot) and much less risky (seriously, on Fedora 8 you install somewhere else and then forcefully raw-copy the data into the container setup? Data integrity alarm bells should be making you deaf by now). LUKS+LVM is officially supported by Slackware Linux since this time, and by the installer basically. To my knowledge I have yet to see any other Linux distribution that understands and can install to a fully encrypted setup like this (much less, my next point is….)

    3) When you can reveal to me what information someone can obtain from an unencrypted root partition (assuming swap and /home are encrypted), let me know. Unless they can get access to the unfiltered memory on the machine (and/or cold-boot the memory but I highly doubt you’re ever going to have anyone that good pursuing your information) there is no other place to get the encryption key you supply with LUKS. The only other way to get at the data is the “angry maid” attack (which applies to both luks+lvm and any simpler setup with an initrd). At most you’re only making life a minute harder for a would-be attacker (because copies of Live Linux CDs are freely downloaded).

    4) The L in LUKS stands for LINUX. They may have the necessary software by now, but they’re not Linux so why are you pestering them? I don’t see Mac or Windows being able to do this in the software level (i.e. encrypted root) so your argument is empty.

    So to summarize, Slackware had it first, Slackware officially supported it first, encrypting the root partition is 99% irrelevant to security assuming you take other smart steps, and you’re unwise to rip on BSD about something that was created for Linux (LUKS and LVM).

    1. Since I’ve never reviewed Slackware, I’ll take your word for it that “Slackware was the first real distribution to be able to encrypt its root partition.” This, of course, implies that there are non-real distributions that had the feature before Slackware 😉

      Your second point leads me to believe that you have not used Fedora since Fedora 8. If you did, you’d know that all it takes to configure encrypted LVM on Fedora is one mouse click. Nothing more. Beats manually creating LUKS+LVM, initrd, and other “extremely easy” stuff. There is a short tutorial about it here.

      On point 3, I am not in a position to reveal to you “what information someone can obtain from an unencrypted root partition,” but that does not been they can not. Your point here implies that encrypting root is not necessary, that encrypting Swap and /home is all that is needed. I find that hard to believe. If that had ended with the implied statement, I’d have cut you some slack, but to explicitly state that “encrypting the root partition is 99% irrelevant to security” makes my head spin. It’s still spinning. In a very bad way, that statement is funny.

      Before you start defending this statement, consider this opening paragraph from the disk encryption chapter of the FreeBSD Handbook:

      File permissions and Mandatory Access Control (MAC) … help prevent unauthorized third-parties from accessing data while the operating system is active and the computer is powered up. However, the permissions enforced by the operating system are irrelevant if an attacker has physical access to a computer and can simply move the computer’s hard drive to another system to copy and analyze the sensitive data.

      Disk encryption is ineffective if an unauthorized party with physical access to your computer can boot it. The point of disk encryption is to deny access to data stored on your computer to people who do not have a right to read it. And there is no better way to enforce that than to make it impossible for them to boot the computer completely. Most distributions do not put /home on a separate partition, so encrypting your home directory wont do you much good.

      Who had it first is not as important as who is doing it right. Btw, my suggestion to the PC-BSD development team (I’m subscribed to their testing mailing list) led to a change in the manner that disk encryption is configured. Grab a snapshot ISO image here and see for yourself.

    2. It’s obvious that you have not kept up with the times. Many distributions do not create a separate partition for /home, so stating that “encrypting the root partition is 99% irrelevant to security” is implying that disk encryption plays no meaningful role in the security posture of a system.

      In PC-BSD, for example, the default partitioning scheme has /home in a jail under /usr, with /usr on a separate partition. Ubuntu and the bevy of distributions based or derived from it place /home under the same partition as /, with the option to encrypt a user’s home directory. And depending on the size of a hard disk, Fedora and other distributions that use Anaconda follow the same script. So you can imagine what not encrypting root in these situations amount to.

  2. But will this version recognize my wireless NIC, TP-LINK TLWN353G/TL ?? pcBSD7 does not, and nowhere can I find a driver or installation protocol that works. Has anyone overcome this problem with pcBSD 7 or 8?



  3. I am currenly installing 8.1 on my laptop. It has I7 with 6gb ram. Install was slow but painless. It still felt a tad sluggish for such a high end machine (vaio F series) with so much ram and such a decent processor.

    Setup is clean, easy to configure, nothing was too hard even for a beginner like myself. I was up and running the internet with firefox skyping with friends in 30 or 40 minutes after I stuck the CD in and booted.

    I look forward to updates. Note it had trouble with my atheros wireless card and nvidia 330m.

  4. Like others on here, I was excited to get my hands on another PC-BSD release. However, I don’t know if it’s BSD’s KDE or if it’s something with the nvidia drivers, but the system was really slow. For example, going through subcategories in the KDE menu created a noticeable stutter. The system takes a considerable amount of time to start-up and just using standard KDE applications makes the system feel sluggish. So unfortunately, PC-BSD didn’t live up to my expectations. Personally, I think it’s a KDE issue because when PC-BSD used KDE 3.5, it was always responsive.

  5. Nice look, but slow and buggy. I’ve installed PC-BSD v8 a total of 3 times on the same machine, and each time, the root password gets corrupted. I can not su and do anything that requires administrative privileges. Going back to 7.1.1. Looking forward to 8.1.

    1. Just tried it again after a re-download/md5 check, & an eon-long install (on my other machine).
      Some of the installed applications wouldn’t work, e.g. music/cd player/VLC, etc.
      SO, I’m erasing the ‘pissy beastie’ & installing Haiku R1/Alpha, which looks promising & interesting, & doesn’t make false claims!
      At least I CAN depend on (hacked) XP with FOSS on this machine!

  6. I really looked forward to this release & tested it, only to find I can’t install my mobile broadband ‘dongle’! (Same goes for OpenSolaris, & Pardus, by the way)

    I also found PC-BSD 8.0 was slow, REALLY slow, like Vista is fast to boot-up in comparison!

    Anyone remember the problems with the Hubble deep-space telescope when it was first ‘booted-up’? I’m sure the problems with 8.0 will be resolved, but, aren’t these things supposed to be sorted in a ‘stable’ release version?

    It would be really nice to live in a world without windows, gates or bills!

  7. Something must be wrong in PC-BSD 8 x64 release or KDE: there never was OS installed of such ill responsiveness on that machine ever. Try to play simple thing as Tetris, and you cannot enjoy because of constantly struggling response, and that’s not because of being picky – shouldn’t be that bad, cause should be hunted and fixed. It is AMD64 2800+ system with 1GB RAM, that is pretty well running either x86 or x64 code.

    Otherwise, installation went well, once big enough partition was given (upgrade of former FreeBSD instance was not successful probably because of that). Also, OS appearance is attractive and rational. Packages of Skype, Java RE, Opera installed and integrated smoothly. Good job, that needs very little fixing to enjoy it in full extent possible.

  8. I really liked PC-BSD 8, it looked good, installed well, was able to use my ATI 3d card( Which has always been a problem for some reason, check the forums), but installing stuff did throw up the issues you spoke about. Using PBIDir was inconsistent again. So much so that unless you’re a diehard PC-BSD fan you’ll go back to the other *BSD’s instead. I have to say though, that if they get their act together, and just hold off releasing a flawed OS, then they’ll certainly do well.

    1. The problem with going back to “the other *BSD’s” is that there is no other desktop BSD to go back to. PC-BSD is the only usable desktop BSD that we have, but it is no yet ready for prime time. Like you said, this was a flawed release.

      1. finid-
        I strongly agree with the limited *BSD options available as a “true” desktop, however, like Gentoo Linux, if take the time to create a desktop properly once, all you have will be updates (not a :20 minute install like Ubuntu or Debian [I love Debian – no disrespect meant here], but at least a progressive day or so). Whilest on this subject, I would like to mention DesktopBSD, which I thought was MUCH better than the PC-BSD project. DesktopBSD was FreeBSD with a front-end that worked flawlessly and when that project collapsed (with what I assumed was because of too much attention being paid to the PC-BSD group), I was floored. It ran great on both x86 and x64 machines (I ran it on both), worked wonderfully with ports/portsnap, and had a hardware recognition system unparalleled by any current BSD out there. As a community, IMHO, we shot ourselves in the foot by letting this flavor slip away………I would return to using it, but the promise of updates is apparently lacking. My appreciation does, however, go out to developers and support team that made it an awesome addition to available desktops out there (AND IT WASN’T BASED (in any way) ON UBUNTU!!!!! – Canonical is a cancer to the Linux community).

        1. As far as I know, DesktopBSD is dead. I’m keeping an eye on DragonFlyBSD. It’s another promising distro, trying to do things it’s won way. As far as Canonical being “a cancer to the Linux community,” I concur. M. Shuttleworth is an opportunist. He’s does not really care about the Free Software community.

          1. -finid

            DesktopBSD may not be completely dead. I still run it upgraded to 7.3 which is supported for a couple of years. There are people on the forums who want to resurect/fork it. It was and still is far superior to PC-BSD and you can just keep it updated by the traditional FreeBSD methods. keep an eye out for http://www.smartbsd.org

  9. I think the new look is great, but unfortunately, that’s where the excitement ended for me. Slow and unresponsive. PBIs failed to work so I went to use ports and I had a blow-up of a proportion that made me stop any further use of PC-BSD, now and probably for a long time to come. Quick reinstall of FreeBSD 7.3, updated a few apps, and I’m home again. PC-BSD looks great, but eye candy really = bloat which usually results in a great looking system that suffers from extremely poor performance.

  10. I tested out this version myself. I had issues using zfs for my root file system… but otherwise things went smoothly. its interesting to note that i was unable to install the freebsd 8 (using their media) on the same machine due to lack of drivers.

    i really enjoyed the KDE from pcbsd. i normally use gnome but have lately tried two other OSes with kde4 out of the box; linux mint kde and kubuntu…. both were extremely buggy with the interface and apps crashing all the time.

    1. i also forgot to mention re zfs… the current freebsd installer can’t handle zfs… so pcbsd is a great choice if you want an easy way to jump head first into zfs.

  11. The problems with playing CDs Kscd are well documented as is with amarok its all down to bad coding from KDE. The latest KDE4.4 nearly solves it but both players still crash at will. I personally think PCBSD really tries to bring BSD to the public and every version improves on the last. The pbi system for software is a good idea as programs are not dependent on each other. PCBSD is closing the gap with Linux at a very fast rate.

Leave a Reply

Your email address will not be published. Required fields are marked *

Get the latest

On social media
Via my newsletter
Mailchimp Signup Form

Partner links

1. Attend Algorithm Conference, a top AI and ML event for 2021.
2. Reasons to use control panel for your server.
3. DHgate Computers Electronics, Cell Phones & more.
Hacking, pentesting distributions

Linux Distributions for Hacking

Experts use these Linux distributions for hacking, digital forensics, and pentesting.


The authors of these books are confirmed to speak during

Algorithm Conference

T-minus AI

Author was the first chairperson of AI for the U.S. Air Force.

The case for killer robots

Author is the Director of the Center for Natural and Artificial Intelligence.

Why greatness cannot be planned

Author works on AI safety as a Senior Research Scientist at Uber AI Labs.

Anastasia Marchenkova

An invitation from Anastasia Marchenkova

Hya, after stints as a quantum researcher at Georgia Tech Quantum Optics & Quantum Telecom Lab, and the University of Maryland Joint Quantum Institute, I’m now working on superconducting qubit quantum processors at Bleximo. I’ll be speaking during Algorithm Conference in Austin, Texas, July 16 – 18, 2020. Meet me there and let’s chat about progress and hype in quantum computing.