Dec 03

[Arch Linux Security Advisory ASA-201412-2] openvpn: denial of service

Arch Linux Security Advisory ASA-201412-2

Severity: High
Date    : 2014-12-02
CVE-ID  : CVE-2014-8104
Package : openvpn
Type    : denial of service
Remote  : Yes
Link    :


The package openvpn before version 2.3.6-1 is vulnerable to denial of


Upgrade to 2.3.6-1.

# pacman -Syu “openvpn>=2.3.6-1”

The problem has been fixed upstream [0] in version 2.3.6.




It was discovered that an authenticated client could trigger an ASSERT()
in OpenVPN by sending a too-short control channel packet to the server.
This could cause the OpenVPN server to crash and deny access to the VPN
to other legitimate users.


A remote authenticated attacker could send specially crafted packets
that could cause the OpenVPN server to crash leading to denial of
service of other legitimate users.

Posted in arch-linux | Tagged , | Leave a comment
Sep 26

[arch-security] [Arch Linux Security Advisory 201409-2] bash: Remote code execution

Arch Linux Security Advisory 201409-2

Severity: Critical
Date    : 2014-09-26
CVE-ID  : CVE-2014-6271, CVE-2014-7169
Package : bash
Type    : Remote code execution
Remote  : Yes
Link    :


The package bash before version 4.3.026-1 is vulnerable to remote code


Upgrade to 4.3.026-1.

$ pacman -Syu “bash>=4.3.026-1”

The problem has not been fixed upstream yet, though some patches were
released [1].


It is possible to work around this issue by replacing bash with a
non-affected shell, for example dash, when specifics bash features are
not needed.


GNU Bash through 4.3 bash43-025 processes trailing strings after
certain malformed function definitions in the values of environment
variables, which allows remote attackers to write to files or possibly
have unknown other impact via a crafted environment, as demonstrated by
vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi
and mod_cgid modules in the Apache HTTP Server, scripts executed by
unspecified DHCP clients, and other situations in which setting the
environment occurs across a privilege boundary from Bash execution.

Posted in arch-linux | Tagged , , | Leave a comment
Sep 26

[arch-security] [Arch Linux Security Advisory 201409-1] NSS: Signature forgery attack

Arch Linux Security Advisory 201409-1

Severity: High
Date    : 2014-09-24
CVE-ID  : CVE-2014-1568
Package : nss
Type    : Signature forgery attack
Remote  : Yes
Link    :


The package nss before version 3.17.1-1 is vulnerable to a signature
forgery attack.


Upgrade to 3.17.1-1.

The problem has been fixed upstream in version 3.17.1.


Antoine Delignat-Lavaud, security researcher at Inria Paris in team
Prosecco, reported an issue in Network Security Services (NSS) libraries
affecting all versions. He discovered that NSS is vulnerable to a
variant of a signature forgery attack previously published by Daniel
Bleichenbacher. This is due to lenient parsing of ASN.1 values involved
in a signature and could lead to the forging of RSA certificates.

The Advanced Threat Research team at Intel Security also independently
discovered and reported this issue.


This vulnerability may allow an attacker to forge false RSA
certificates, considered valid by applications, like Firefox or
Thunderbird, that rely on NSS to valid certificates.
This could for example be used to conduct Man-In-The-Middle attack.

Posted in arch-linux | Tagged | Leave a comment
Aug 24

Arch Linux: Your flexible friend

Arch is aimed at intermediate or advanced Linux users, since terminal commands and manual editing of configuration files are de rigueur. The Arch wiki provides thorough documentation though, so even if you’ve dabbled with Ubuntu or Mint and like a challenge, then feel free to give it a shot on a spare (or virtual) machine.

If the install process doesn’t put you off then the chances are you’ll get on fine. Arch aims to expose as much of the system as possible to the user, but to have these internals arranged in a coherent manner. So with a bit of patience there is potential to really advance your skills. On the other hand, if you just tried Ubuntu and are looking for an alternative because you ran into difficulties, Arch is unlikely to solve your problems. However, Manjaro Linux, an Arch derivative with more of a focus on user- friendliness, might just be the answer.

Discerning Arch users enjoy up to the minute releases of graphics drivers (wholesome and proprietary), web browsers, and pretty much any software you would care to name. It’s often a sore point on the Ubuntu Forums that Canonical’s repos lag behind developer releases. Then again, those forums have plenty of sore points, and a conservative update strategy does allow for a more thoroughly tested and stable distribution. Speaking of which, the stable releases of Debian happen once every three years, so at the time of writing while Arch users are enjoying the shiny new 3.15 kernel, users of the current stable release of Debian (codenamed Wheezy) are still rocking the 3.2 series. Of course, this branch is still maintained, and any security fixes are applied promptly. And in fairness, Debian users can use backports to get newer versions of certain software, but not those – such as Gnome – that depend on so many new libraries. Likewise, Ubuntu has PPAs, Gentoo has Overlays and Fedora has other repos, such as RPM Fusion.

Currently, Arch Linux distributes packages for two architectures: i686 (32-bit) and x86_64 (64-bit). This greatly simplifies the process of maintaining and testing new packages. When it was released (and commodity 64-bit processors were still two years away) only i686 was supported. Part of its popularity was due to support for this microarchitecture, inaugurated in the Pentium Pro chips of 1995. Other distributions were still stuck supporting i386 architectures, so Arch was seen as a speedier option. Estimates suggest that nowadays less than 10% of users are using the i686 version, so it’s conceivable that future support for this architecture will go the way of the dodo. However, since there is still some need to run 32-bit binaries – and hence maintain the multilib repository of 32-bit support libraries – the small overhead that comes with maintaining i686 alongside x86_64 is at least in part warranted.

Installing Arch

You can install Arch Linux in the usual way by downloading an ISO image and making a

bootable CD or USB stick. It’s also possible to do it from an existing Linux install, although there are caveats for this approach. If you are installing onto the same drive as the existing install, then you will be unable to repartition it without recourse to a boot CD. Also, it’s more or less impossible to install a 64-bit Arch system from another 32-bit Linux. The other direction, while possible, is nonetheless far from trivial.

In sum, if you have a CD drive or a spare USB stick, stay with the traditional approach.

If you were expecting a swish graphical installer that sets everything up for you with a couple of simple questions and a high speed progress bar, then prepare for disappointment. The install medium summarily dumps you at a zsh prompt, leaving it up to you to set up your disks, network connections, and localisation.

The installer includes everything you need to set up a GPT-partitioned drive, if that’s your will, but you might want to do this using a live Gparted CD because cgdisk, gdisk or parted may cause pain and suffering. All of this is covered more than adequately in the official Beginners’ Installation Guide ( BeginArch), so we shall only provide an overview here.

The oft-troublesome wireless firmware images are included in this live environment, so it should be possible to (avoiding the Catch-22 situation engendered in their absence) get your wireless card working. Once everything is set up you can download and install a (very) minimal installation to the target partition, using the pacstrap script, and generate an fstab file. You can then chroot into your new install and (joy of joys) perform much of the same configuration that you just did for the live environment, as well as some additional tasks. It’s a good idea to get your wireless permanently set up at this point.

So you ought to install the linux-firmware package, or whichever package is required for your wireless card, and add the required kernel module to a .conf file in /etc/modules-load.d/.

Arch provides a great little tool called netctlfor managing your network connections. This handles everything from simple static IP Ethernet connections to VPNs and credential-based wireless networks with remarkable aplomb. Whatever your setup, you’ll want to make a profile in /etc/ netctl, most likely there’s an example that closely resembles your requirements, so this is pretty painless. For simple WPA(2) networks, you can even use the wifi-menu tool to generate one for you. For laptop users (or anyone who often switches between networks) you can use the netctl-ifplugd (for wired) or netctl-auto (for wireless) services to dynamically connect to known networks.

Finally, you’ll need to set up a root password and to install a bootloader, of which there are several. The mainstream choice here is Grub, but whatever you choose ensure you follow the instructions carefully: nobody wants an unbootable system. Take particular heed of the extra instructions for UEFI motherboards. And there you have it, a (hopefully) fully functioning Arch Install. But what can it do? Read on, dear reader, read on.

All the official packages follow the developers’ releases as closely as possible, but not without thorough testing so that stability is not sacrificed. Arch is an example of what is termed a ‘rolling release’ model, so with very few exceptions, as long as you pacman -Syu regularly, your installation will always be kept up-to-date. There are no discrete distribution upgrades every six months or three years or at sunspot maximum (an 11-year cycle, btw). The ISO releases are just snapshots of the current core packages. When Gnome 3.12 was released in March, it received positive reviews (on account of righting many of the wrongs of the 3.x line) but couldn’t be incorporated into the conservative release cycles of the other major distros. As such, some people dubbed it a ‘desktop without a home’. Of course, in certain distributions, you could shoehorn it in via third party repositories (or using Gentoo), but many users (and normal people) avoid such unsavoury practices. On Arch, by contrast, the new release was packaged and waiting as soon as the release happened.

Keep on rolling

It’s partly thanks to the elegant and simple way that the Arch internals are arranged that this rolling release model works.

It enabled the developers to move everyone off SysVInitand onto Systemdwith harmonious synchronicity and to sneak package signing into Pacman in the blink of an eye. The filesystem package contains the base directory layout and core configuration files in /etc , so by making changes to this package a new layout could be promulgated. And so it was back in ‘13, when ‘twas decreed that the /bin, /sbin and /usr/ sbin directories were superfluous and binaries residing therein should instead be placed in /usr/bin. This sort of low-level rejig couldn’t happen in the traditional release model, where such configurations are decided in advance and stuck with until a new release is conceived. That said, the /usr/bin move did bite a few people, primarily those using non­official packages. An advisory was placed on the Arch homepage (archived at http://bit. ly/1i7jWqF), but unfortunately many ignored this and the warnings that Pacman emitted. Tears resulted. These Intervention Required notices are necessary periodically, but they usually concern only particular components, rather than system-wide overhauls. In any case, if an update has potential to harm your system, then it ought to fail before anything is actioned, at which point you should direct the optical organs toward before commencing blind and frantic meddling. Only by manually forcing the issue can destruction be wrought.

As new versions of packages are pushed to the repos, others that depend on them will have to be upgraded, or at least rebuilt, in order to avoid breakage. The Arch team does a sterling job of maintaining consistency across all the official packages to avoid compatibility being threatened by such a version bump, but its ultimately up to the user to ensure they upgrade in a sane manner. Doing partial upgrades is therefore highly discouraged, since this could result in a broken system. Either upgrade everything (with pacman -Syu) or nothing. New packages, along with those that are built against them, are staged in the testing repository. While its tempting for new users to enable this in the hopes of getting bleeding- edge software, such a course of action is far from prudent. Things are in testing to test if they break. If they do. then you get to keep all the pteces.

man pacman

Arch’s package manager goes by the name of Pacman. Being lightweight, fast and simple, it epitomises the Arch Way. The heavy lifting is really done by a backend library called hbalpm. Pacman checks in with official or unofficial repositories that hold packages in the .pkg.tar. xz format. These are LZMA2 compressed tarballs containing the packages files and directones as well as some other files containing package metadata, checksums. post-(un)installation scripts and the like.

There are three official repos a default Arch installation uses:

»Core The base system you get on install.

» Extra Other officially maintained packages.

»Community Contains packages voted for by the Arch community. Trusted users’ rather than official Arch devs maintain community packages, but that doesn’t mean people can’t make their own Arch packages.

Besides dealing with individual packages. Pacman a Iso supports package groups. If you want to do anything involving compilation.

You’ll need the basedevel group. This includes gcc. makeand all the other utilities that make them work their magic. Gnome. MATE. LXDE and KDE desktops are groups as well, so you can choose which bits of these giants you want to install. The KDE group is a behemoth

–               it comprises in excess of 200 packages, but fortunately there’s a group called kde-meta that collates these into 16 subgroups, easing the picking and choosing process.

As packages are upgraded, new configuration files are shipped that may or may not conflict with the previous ones: users may have made modifications or defaults may have changed. Pacman checks the md5sum of the current file to see if the user has made any modifications. If not. then it’s overwritten with the new file. Pacmans mechanism for dealing with the other case is to install the new configuration file with the extension .pacnew.

A message is emitted to this effect and it’s up to the user to make any pertinent changes, preferably immediately after the upgrade.

You can check the differences using standard tools – for example, if the openssh package ships a new sshd_config.

S diff /etc/ssh/sshd_config{, pacnew}

Note the use of Bash expansion to save us keystrokes. The user will want to incorporate any new settings together with any customisations into the new file. If there aren’t too many of the latter then it’s easier just to edit the .pacnew file and overwrite trie original.

The makepkg and Pacman tools are really just components of what’s known as the ABS. or Arch Build System. This also consists of the ABS tree, which is a hierarchy containing PKGBUILDs for all the official Arch packages. By installing the abs package on your machine and running the abs command, you will find yourself with a copy of this tree in /var/abs. Armed with this, and the base-devel package, you can then modify the official packages to your heart’s content: enabling/disabling extra features, using specific software versions or customising CFLAGS. Regarding the latter, it’s possible, thanks to the pacbuilderscript, to recompile your whole system with -03 Such foolhardy behaviour is not just the preserve of Gentoo users. Support for 386 processors was dropped from the kernel in version 3.8 (“Good riddance.” said Linus). But if you’re still bitter that Arch won’t run on your 386. you could use pacbuilder, an older kernel, a lot of ingenuity and your copious free time to remedy this situation. And that concludes our coverage of a truly glorious distro. May your wanderings through the Archian plains be fruitful and enjoyable, your system be snappy and your configuration files all up-to-date.

Posted in Uncategorized | Leave a comment
Jul 29

xorg-server 1.16 is now available

The new version comes with the following changes:

* X is now rootless with the help of systemd-logind, this also means that it
must be launched from the same virtual terminal as was used to log in,
redirecting stderr also breaks rootless login. The old root execution behavior
can be restored through the Xorg.wrap config file (man xorg.wrap). Please note
that launching X through a login-manager (gdm, kdm, …) doesn’t yet provide
rootless access.

* The default configuration files are now in /usr/share/X11/xorg.conf.d, all
host configurations are still taking place in /etc/X11/xorg.conf.d/ directory.
Please note that files 10-evdev.conf and 10-quirks.conf in /etc/X11/xorg.conf.d
could be renamed with .pacsave suffix, which could break your configuration,
then just rename them and remove the .pacsave suffix.

* Better glamor accelerated rendering, deprecating `glamor-egl` package.

* A new package `xorg-server-xwayland` that allows running X applications
inside a wayland session.

* The `xf86-video-intel` package doesn’t provide dri3 support anymore because
of multiple rendering bugs.


Posted in Uncategorized | Tagged , | Leave a comment