Augeas versions up to and including 1.8.0 are vulnerable to heap-based buffer overflow due to improper handling of escaped strings. Attacker could send crafted strings that would cause the application using augeas to copy past the end of a buffer, leading to a crash or possible code execution.

A vulnerability has been found in Hercules Augeas 1.14.1 and classified as problematic. This vulnerability affects the function recaseexpand of the file src/fa.c. The manipulation of the argument re leads to null pointer dereference. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.

Augeas upstream commit 051c73a9:

https://github.com/hercules-team/augeas/commit/051c73a9

introduced a flaw in the way Augeas sets permissions on newly created files. The above commit aims to address a regression introduced in the fix for CVE-2012-0786 (see bug 772257 comment 39), which introduced a use of mkstemp() to create new files. mkstemp() always sets 0600 file permissions regardless of the current umask setting. Commit 051c73a9 attempts to fix file permissions based on umask setting, but it does not correctly handle certain umask values, causing Augeas to make newly created files world writable. A local user could possibly use this flaw to modify configuration files created by an application using Augeas.

Augeas is a configuration management API that represents the contents of config files as a tree in memory for editing, with the edits being written back to the actual file. By default it loads files it understands in a large number of standard system locations (/etc, /boot), but can also open files in a user specified location [1],[2].

It has two save modes of interest, "backup" that keeps the original in PATH.augorig and "newfile" that leaves the file alone, but writes the edited version to PATH.augnew. These can be set via the API [3] or --backup/--new with augtool (CLI tool around the API).

A flaw was found in the current 0.10.0 version and most previous versions. It requires that the directory containing the file to be edited is writable by another user, so this needs the user to explicitly open a file in another location or for a file in a default location to be in a group/world writable directory.

This attack hinges on behaviour to support writing to a bind mount (ticket #32 gives some history [4] relating to oVirt?) when doing the rename fails with EBUSY or EXDEV. Augeas instead opens the file and writes straight into it, see transform.c in clonefile when copyifrenamefails is set from transformsave.

In two of the three, copyifrenamefails is only set if the node /augeas/save/copyifrenamefails is created by the user to enable the behaviour [4]. I think there are three ways to exploit this code.

1) with --backup

When creating PATH.augsave, copyifrenamefails is always set to 1. A bind mount of a single file (or FUSE, enabling non-privileged attacks?) at PATH.augsave would cause the file contents to be written to the bind mounted file.

2) with --new and /augeas/save/copyifrenamefails

As above, but create bind mount at PATH.augnew.

3) with --backup and /augeas/save/copyifrenamefails

Augeas first moves PATH to PATH.augsave for the backup, then renames PATH.augnew to PATH. There's a tiny window in which a bind mount could be created at PATH, so the file contents are written to the bind mounted file.

[1] http://augeas.net/page/Loadingspecificfiles [2] https://github.com/raphink/augeas-sandbox/blob/master/augload [3] http://augeas.net/docs/api.html#saving-the-tree [4] https://fedorahosted.org/augeas/ticket/32

The transformsave function in transform.c in Augeas before 1.0.0 allows local users to overwrite arbitrary files and obtain sensitive information via a symlink attack on a .augsave file in a backup save action, a different vector than CVE-2012-0786.

Augeas is a configuration management API that represents the contents of config files as a tree in memory for editing, with the edits being written back to the actual file. By default it loads files it understands in a large number of standard system locations (/etc, /boot), but can also open files in a user specified location [1],[2].

It has two save modes of interest, "backup" that keeps the original in PATH.augorig and "newfile" that leaves the file alone, but writes the edited version to PATH.augnew. These can be set via the API [3] or --backup/--new with augtool (CLI tool around the API).

A flaw was found in the current 0.10.0 version and most previous versions. It requires that the directory containing the file to be edited is writable by another user, so this needs the user to explicitly open a file in another location or for a file in a default location to be in a group/world writable directory.

Augeas always opens PATH.augnew for writing, sets the file modes identically to PATH, writes the file contents and then renames PATH.augnew to PATH.

Creation of a symlink at PATH.augnew will cause the new file contents to be written to the symlink target and then the symlink is moved to PATH. This enables an attacker to get to the file contents in the symlink target and also subvert PATH.

The code's at src/transform.c in transformsave [4].

[1] http://augeas.net/page/Loadingspecificfiles [2] https://github.com/raphink/augeas-sandbox/blob/master/augload [3] http://augeas.net/docs/api.html#saving-the-tree [4] https://git.fedorahosted.org/cgit/augeas.git/tree/src/transform.c?id=547442f#n885