- Security of Deb and Other Files
You can find a .deb file for a package somewhere on the Internet. Then you can use dpkg -i package.deb
and install it. That's no better than picking up an install for Windows somewhere on the Internet. Don't do it unless you are absolutely sure of the source, and even then make sure you have all of the prerequisite packages already installed.
Deb files, safe or not, do follow a format with hashes, etc. so that they have to be rebuilt if they are changed.
Package (.deb files) in the Ubuntu repositores are generally built from source on Launchpad build computers so the contents of the .deb file matches the source, and the source can be viewed by anyone. Many packages have teams maintaining them who follow them and are on the lookout for security problems. New source package versions have to be signed properly by gpg keys using public key cryptography before they can be built.
There are now binary only packages available in the Ubuntu Software Center, so the public can't view the source of those. I don't know about these for sure, but I believe they are reviewed before they are made available.
You generally shouldn't install a package with dpkg -i package.deb
, but use apt-get or the software center instead, downloading from an Ubuntu repository. You should also avoid picking up any other kind of script that you can't look at and understand completely before you run it.
The multi-user system Unix-like systems do mean that if you make a mistake you can mess up your account and its files, but not the accounts and settings of other users that have been established on the same system, nor the operating system itself.
The exception is when you run a command with sudo
or have to enter a password to install a package or do other maintenance. These are the times to be very careful about the source of what you are doing. This is very similar to using UAC.
- Executable Files on Removable Media
As long as you are using due care, I don't think you need to maintain programs on removable media. Like Windows, most programs are installed as packages and therefore aren't runnable from removable media (although you could put an entire Ubuntu on a flash drive if you want).
As I mentioned above, .deb files use hashes for the files they include to see that they aren't altered by an attacker. Ubuntu repositories also have gpg keys stored on your system when you install Ubuntu, and there is a signature and chain of hashes followed down to the .deb files to keep things secure. Ubuntu is derived from Debian and that project created this approach.
There are things like autorun in Linux and other Unix-like systems. When you install packages those packages can cause programs to start at boot time, or when a user logs in to a terminal, or when a user logs into a GUI session. Most users have a (hidden by default) .bashrc file in their home directories that execute when a user logs in to a terminal.
The Ubuntu download web site not only has the .iso files for CD's and DVD's but also message digests (hashes) you can check to make sure the file you retrieved is authentic down to the bit.
Despite everything else, developers make mistakes and potential security problems can creep into software. Running supported versions of Ubuntu means that you will be offered security fixes for items in the main Ubuntu repositories, and often for items in the universe and other repositories. You should apply those fixes. Long-term-support releases like 12.04 (Precise) offer this service for a longer term than other releases of Ubuntu.
I can't personally guarantee that the precautions are perfect, but I think they are pretty good for the current state of the art.
Best Answer
Stack Clash is an exploit based on a fairly old technique. The memory used by a process is divided into two regions - the stack and the heap. One generally imagines the stack as growing downwards and the heap as growing upwards. What happens when the either grows enough to clash with the other? More generally, what happens when the stack grows enough to encroach into unrelated memory spaces? The original vulnerability is 12 years old, and the Linux kernel developers fixed it temporarily by using a guard page. However, researchers at Qualys have managed to exploit this despite the guard page.
Ars Technica reports:
Quoting the LWN article about the original fix from 2010:
The above description applies to various Unix-like kernels.
While Ars Technica does note a temporary workaround mentioned in the Qualys report ("set the hard RLIMIT STACK and RLIMIT_AS of local users and remote services to a low value"), it should be noted that this doesn't necessarily safeguard against this exploit. The only safe way out currently is to upgrade. According to the grsecurity analysis:
The best we can do now is upgrade the kernel to a patched version.
The 2010 exploit used the X server, this one used sudo, the next one could be any of a multitude of userland programs that, at some point, run under elevated privileges.
Qualys has not published any proof-of-concept code for exploits as yet (they plan to do so at a later date).
There are multiple Ubuntu Security Notices associated with CVE-2017-1000364:
Also note that the CVE tracker lists several release/kernel combinations as pending fixes.
Generally, the simplest fix is to update your systems to the latest kernel package ASAP.
The relevant kernel versions from the USNs (culled using
for i in {24..35}; curl -s https://www.ubuntu.com/usn/usn-33$i-1/ | pup 'dl:nth-last-of-type(1)'
):Sudo
The aforementioned sudo bug is covered by USN-3304-1, from May 30, 2017: