You’re using Linux Disk Encryption? Can be bypassed by pressing ‘ENTER’ for 70 seconds!

A really dumb bug, but with a really simple fix!

A vulnerability in Cryptsetup, a utility used to set up encrypted filesystems on Linux distributions, could allow an attacker to retrieve a root rescue shell on some systems.

The security issue was discovered by the security researcher Hector Marco and relies to a vulnerability (CVE-2016–4484) in the implementation of the Cryptsetup utility used for encrypting hard drives via Linux Unified Key Setup (LUKS, the standard implementation of disk encryption on a Linux-based operating system).

The Cryptsetup utility has a strange way to handle password failures for the decryption process when a system boots up, permitting a user retry the password multiple times.

When a user reach 93 password attempts, it is dropped to a shell that has root privileges.

In other words, if you enter a blank password 93 times — or simply hold down the ‘Enter’ key for roughly 70 seconds — you will gain access to a root initramfs shell.

I can fix it?

If your distribution is vulnerable and a patch is not yet available, the vulnerability can be fixed by modifying grub configuration, adding the “panic” parameter to the kernel in order to prevent a shell:

# sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT="/GRUB_CMDLINE_LINUX_DEFAULT="panic=5 /' /etc/default/grub
# grub-install

More technical information on Hector Marco’s website

Streaming media contents from Linux to Chromecast?

It’s simple, with Stream2Chromecast!

Are you searching for an easy way to stream media files from your LinuxBox to a Chromecast?

You can use Stream2chromecast, a simple Python script that makes the task of streaming media files to a Chromecast device ridiculously easy.

Simply clone the project’s GitHub repository with this command

git clone

Now, to stream a media content, start the script with this command line /path/to/foo.mp4

The utility also supports basic playback controls through -pause, -continue and -stop options.


Only the WebVTT format is currently supported.

If you have an SRT subtitle file, you can convert it with this online tool:

To cast the subtitles on /path/to/subtitles.vtt use this command: -subtitles /path/to/subtitles.vtt /path/to/foo.mp4

More info and download

Dirty COW (CVE-2016–5195): a 0-day local privilege escalation vulnerability in the Linux kernel…

Any user can become root in less than 5 seconds!

The bug has existed since Linux kernel version 2.6.22 and was found by Phil Oester.

Exploitation of this bug does not leave any trace of anything abnormal happening to the logs. 
So you can not detect if someone has exploited this against your server.

From official page:

A race condition was found in the way the Linux kernel’s memory subsystem handled the copy-on-write (COW) breakage of private read-only memory mappings.


  • An unprivileged local user could use this flaw to gain write access to otherwise read-only memory mappings and thus increase their privileges on the system.
  • This flaw allows an attacker with a local system account to modify on-disk binaries, bypassing the standard permission mechanisms that would prevent modification without an appropriate permission set.

How to determine if your system is vulnerable

For RHEL/CentOS Linux, use the following script:

$ wget
$ bash

For all other distro you can try the POC, that rewrites a file owned by root:

$ wget

Run it first as root:

$ sudo -s
# echo this is not a test > foo

Then run this as normal user:

$ gcc -lpthread dirtyc0w.c -o dirtyc0w
$ ./dirtyc0w foo m00000000000000000
mmap 56123000
madvise 0
procselfmem 1800000000
$ cat foo

How to fix?

Simply update your linux distribution! :-)


$ sudo yum update
$ sudo reboot


sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade
sudo reboot

Links and references

VirtualBox on Linux: solve USB access problems

With just a simple command!

Have you just installed VirtualBox on your Linux Box, but the virtual machine cannot access the host’s USB ports?

It’s just a permission issue: simply run VirtualBox as root, or (more correctly) add you user account to the vboxusers group:

sudo usermod -aG vboxusers <your username>

It’s easy! :-)

Small interesting *nix facts: the infamous fork bomb

Maybe it’s a dated topic, but it’s always funny!

What is a fork bomb?

A fork bomb (also know as Rabbit Virus or Wabbit) is a denial-of-service attack wherein a process continually replicates itself, slowing down or crashing the system due to resource starvation.

Some examples?

Bash version:


Its construction is elegant and deadly, bringing any system to halt if the proper security measures aren’t put in place.

The command simply creates a function named : with the :() in the beginning, it then goes on to define the contents of the function with {:|:&}, this again is very simple as it only executes itself and pipes into another call of itself while backgrounding the process.

Finally, the function definition is terminated with the ; and called with the :.

Another BASH implementation, as a script:


In this case, $0 returns the name of the shell script itself in recursive loop.

Windows Batch Version:


same technique of the bash version.

Perl Version:

perl -e "fork while fork" &

and Python:

import os
while 1:

Use with caution! :-)

Five complete solutions for email server deploy

For inexperienced or impatient admins!

Five complete solutions for rapidly deploy a complete mail server with a single installation. Enjoy!

  • Citadel: Versatile and powerful mail server, written in C.
    License: GPLv3
  • iRedMail: Mail server solution based on Postfix and Dovecot.
    License: GPLv3
  • Mailcow: Mail server suite based on Dovecot, Postfix and other open source software. Provides a PHP Web UI for administration. 
    License: GPLv2
  • Mail-in-a-Box: Shell script that turns Ubuntu into a fully functional mail server.
    License: CC0
  • Modoboa: Mail hosting and management platform with web interface, written in Python.
    License: MIT

How to prevent the huge CPU usage of gnome-keyring-daemon when starting Google Chrome

Let’s try to mitigate an annoying behavior of Google Chrome on Linux

If you using the (useful!) data synchronization feature of Google Chrome, you may encounter an unusual CPU usage from gnome-keyring-daemon process when the browser starts: the gnome-keyring-daemon eats all CPU time for 4/5 minutes.

This happens because by default Google Chrome uses the system keychain to store passwords: if the data to be synchronized are many, this problem can occur.

How to fix it?

Unfortunately it does not seem to be a configuration flag (in chrome://flags/) to disable the use of gnome-keyring, but it is available a command line argument that lets you save passwords on files, without using the system keychain:

Set the password store to use. The default is to automatically detect based on the desktop environment. basic selects the
built in, unencrypted password store. gnome selects Gnome keyring. kwallet selects (KDE) KWallet. (Note that KWallet may not
work reliably outside KDE.)

If Chrome is started with the “— password-store=basic” parameter, it stores all password into an unencrypted file on user profile:

google-chrome --password-store:basic

Obviously, the price to pay is to store all the passwords on an unencrypted file (but the problem can be mitigated by applying encryption to the whole disk or to the user’s home directory).

How to create a custom button on the Unity Launcher…

…to start Google Chrome always with the “ — password-store=basic” argument?

It’s pretty simple: just copy the file /usr/share/applications/google-chrome-beta.desktop into ~/.local/share/applications/.

Then edit the copied file and change the entry Name

and the entry Exec like this:

After saving the file, a new Google Chrome icon should appear into the Unity Launcher:

Now, simply drag the new icon on the launcher:

That’s it!