In the Linux Kernel 4.11 a new system-call statx() was introduced. The old stat() system-call is used to get meta-data(like size, permissions aso.) of files and directories. Stat() lacks functionallity for remote filesystems and collects all the information of a file at once which might lead to slow operations. Statx() is a new implementation of stat. The caller can request specific information(like just the size of a file) to speed up the call. If the filesystem is a remote filesystem, it is possible to let statx() first sync with the remote-server before requesting the information(or just be fine with the cached infos). Another nice feature is that statx() can also be used to get extra fileattributes like: “is the file encrypted or compressed?”.

In kernel-programming we should avoid doing call_usermodehelper() which allows to execute a command from kernel-space. And sometimes we even want to call this function within a systemcall. Normally, we really don’t wanna do this. But, desperate times require extraordinary methods.

I am currently writing a work about containers and I found this amazing blog which explains containers in 500 lines of code(and about 3000 lines of very well structured text). I can definitely recommend Lizzies-Blog.

Eric Dumazet of Google found a very dangerous remote execution bug in the Linux Kernel. It’s located in the recv-syscall with the MSG_PEEK-flag set. Attackers can remotely execute code on the target..

I used a google-dork to find vulnerable software:

 MSG\_PEEK filetype:c 

And found some possible targets:

The latest wikileaks revealings gave also insights about an interesting bug in cisco products. No I am not talking about the bug in the Cisco Cluster Management Protocol (CMP). I am talking about the open telnet ports.Ten years ago it was already recommended to use ssh instead and there are still so many devices out there with open telnet ports. Now it really is time to close them.

It’s 3/14 - Happy PI Day

The Electronic Frontier Foundation released guidelines for protecting your data when you pass the U.S. Border.

During my research about update mechanisms of open-source software I discovered vulnerabilities in OpenElec.

Overview

• System affected: OpenElec
• CVE: CVE-2017-6445
• Vulnerable component: auto-update feature
• Software-Version: 6.0.3, 7.0.1
• User-Interaction: Reboot required
• Impact: Remote Code Execution with root permission

If I enable postscreen on a Debian-Host I’ll get this strange message in my mail.log:

Feb 13 08:38:37 tardis postfix/postscreen[17453]: close database /var/lib/postfix/postscreen_cache.db: No such file or directory (possible Berkeley DB bug)

It looks like the postscreen_cache.db-file is located in /var/lib/postfix instead of the postfix-jail /var/spool/postfix/var/lib/postfix. So we can fix it by moving the file into the jail: