.\" Automatically generated by Podwrapper::Man 1.32.7 (Pod::Simple 3.32)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings.  \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
.    ds -- \(*W-
.    ds PI pi
.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
.    ds L" ""
.    ds R" ""
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds -- \|\(em\|
.    ds PI \(*p
.    ds L" ``
.    ds R" ''
.    ds C`
.    ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\"
.\" If the F register is >0, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.if !\nF .nr F 0
.if \nF>0 \{\
.    de IX
.    tm Index:\\$1\t\\n%\t"\\$2"
..
.    if !\nF==2 \{\
.        nr % 0
.        nr F 2
.    \}
.\}
.\" ========================================================================
.\"
.IX Title "guestfs-security 1"
.TH guestfs-security 1 "2016-08-08" "libguestfs-1.32.7" "Virtualization Support"
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH "名前"
.IX Header "名前"
guestfs-security \- security of libguestfs
.SH "説明"
.IX Header "説明"
This manual page discusses security implications of using libguestfs,
particularly with untrusted or malicious guests or disk images.
.SS "ファイルシステムのマウントに関するセキュリティ"
.IX Subsection "ファイルシステムのマウントに関するセキュリティ"
You should never mount an untrusted guest filesystem directly on your host
kernel (eg. using loopback or kpartx).
.PP
When you mount a filesystem, mistakes in the kernel filesystem (\s-1VFS\s0)  can be
escalated into exploits by attackers creating a malicious filesystem.  These
exploits are very severe for two reasons.  Firstly there are very many
filesystem drivers in the kernel, and many of them are infrequently used and
not much developer attention has been paid to the code.  Linux userspace
helps potential crackers by detecting the filesystem type and automatically
choosing the right \s-1VFS\s0 driver, even if that filesystem type is unexpected.
Secondly, a kernel-level exploit is like a local root exploit (worse in some
ways), giving immediate and total access to the system right down to the
hardware level.
.PP
These exploits can be present in the kernel for a very long time
(https://lwn.net/Articles/538898/).
.PP
Libguestfs provides a layered approach to protecting you from exploits:
.PP
.Vb 9
\&   untrusted filesystem
\& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\&   appliance kernel
\& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\&   qemu process running as non\-root
\& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\&   sVirt [if using libvirt + SELinux]
\& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\&   host kernel
.Ve
.PP
We run a Linux kernel inside a qemu virtual machine, usually running as a
non-root user.  The attacker would need to write a filesystem which first
exploited the kernel, and then exploited either qemu virtualization (eg. a
faulty qemu driver) or the libguestfs protocol, and finally to be as serious
as the host kernel exploit it would need to escalate its privileges to
root.  Additionally if you use the libvirt back end and SELinux, sVirt is
used to confine the qemu process.  This multi-step escalation, performed by
a static piece of data, is thought to be extremely hard to do, although we
never say 'never' about security issues.
.PP
Callers can also reduce the attack surface by forcing the filesystem type
when mounting (use \*(L"guestfs_mount_vfs\*(R" in \fIguestfs\fR\|(3)).
.SS "一般的なセキュリティ考慮事項"
.IX Subsection "一般的なセキュリティ考慮事項"
Be careful with any files or data that you download from a guest (by
\&\*(L"download\*(R" we mean not just the \*(L"guestfs_download\*(R" in \fIguestfs\fR\|(3) command but
any command that reads files, filenames, directories or anything else from a
disk image).  An attacker could manipulate the data to fool your program
into doing the wrong thing.  Consider cases such as:
.IP "\(bu" 4
データ（ファイルなど）が存在しない場合
.IP "\(bu" 4
存在するが空の場合
.IP "\(bu" 4
通常よりもかなり大きい場合
.IP "\(bu" 4
任意の 8 ビットのデータを含む場合
.IP "\(bu" 4
予期しない文字エンコードを使用している場合
.IP "\(bu" 4
同型異義語を含む場合
.SS "プロトコルセキュリティ"
.IX Subsection "プロトコルセキュリティ"
プロトコルは、定義されたメッセージ上限容量を持つ \s-1RFC 4506 \s0(\s-1XDR\s0)
に基づき、セキュアであるように設計されています。しかしながら、libguestfs を使用するプログラムは気をつけなければいけません \-
たとえば、ディスクイメージからバイナリーをダウンロードして、ローカルに実行するプログラムを書くことができます。また、多くのプロトコルセキュリティは結果からあなたを保護しません。
.SS "\s-1INSPECTION SECURITY\s0"
.IX Subsection "INSPECTION SECURITY"
Parts of the inspection \s-1API \s0(see \*(L"\s-1INSPECTION\*(R"\s0 in \fIguestfs\fR\|(3)) return untrusted
strings directly from the guest, and these could contain any 8 bit data.
Callers should be careful to escape these before printing them to a
structured file (for example, use \s-1HTML\s0 escaping if creating a web page).
.PP
Guest configuration may be altered in unusual ways by the administrator of
the virtual machine, and may not reflect reality (particularly for untrusted
or actively malicious guests).  For example we parse the hostname from
configuration files like \fI/etc/sysconfig/network\fR that we find in the
guest, but the guest administrator can easily manipulate these files to
provide the wrong hostname.
.PP
The inspection \s-1API\s0 parses guest configuration using two external libraries:
Augeas (Linux configuration) and hivex (Windows Registry).  Both are
designed to be robust in the face of malicious data, although denial of
service attacks are still possible, for example with oversized configuration
files.
.SS "\s-1RUNNING UNTRUSTED GUEST COMMANDS\s0"
.IX Subsection "RUNNING UNTRUSTED GUEST COMMANDS"
Be very cautious about running commands from the guest.  By running a
command in the guest, you are giving \s-1CPU\s0 time to a binary that you do not
control, under the same user account as the library, albeit wrapped in qemu
virtualization.  More information and alternatives can be found in
\&\*(L"\s-1RUNNING COMMANDS\*(R"\s0 in \fIguestfs\fR\|(3).
.SS "\s-1CVE\-2010\-3851\s0"
.IX Subsection "CVE-2010-3851"
https://bugzilla.redhat.com/642934
.PP
このセキュリティバグは、QEMU のディスクイメージでないことをディスクの自動フォーマット検出に関するものです。
.PP
A raw disk image is just the raw bytes, there is no header.  Other disk
images like qcow2 contain a special header.  Qemu deals with this by looking
for one of the known headers, and if none is found then assuming the disk
image must be raw.
.PP
This allows a guest which has been given a raw disk image to write some
other header.  At next boot (or when the disk image is accessed by
libguestfs) qemu would do autodetection and think the disk image format was,
say, qcow2 based on the header written by the guest.
.PP
This in itself would not be a problem, but qcow2 offers many features, one
of which is to allow a disk image to refer to another image (called the
\&\*(L"backing disk\*(R").  It does this by placing the path to the backing disk into
the qcow2 header.  This path is not validated and could point to any host
file (eg. \*(L"/etc/passwd\*(R").  The backing disk is then exposed through \*(L"holes\*(R"
in the qcow2 disk image, which of course is completely under the control of
the attacker.
.PP
In libguestfs this is rather hard to exploit except under two circumstances:
.IP "1." 4
ネットワークを有効化しているか、もしくは書き込みモードでディスクを開いています。
.IP "2." 4
You are also running untrusted code from the guest (see \*(L"\s-1RUNNING
COMMANDS\*(R"\s0 in \fIguestfs\fR\|(3)).
.PP
The way to avoid this is to specify the expected disk format when adding
disks (the optional \f(CW\*(C`format\*(C'\fR option to
\&\*(L"guestfs_add_drive_opts\*(R" in \fIguestfs\fR\|(3)).  You should always do this if the
disk is raw format, and it's a good idea for other cases too.  (See also
\&\*(L"\s-1DISK IMAGE FORMATS\*(R"\s0 in \fIguestfs\fR\|(3)).
.PP
For disks added from libvirt using calls like
\&\*(L"guestfs_add_domain\*(R" in \fIguestfs\fR\|(3), the format is fetched from libvirt and
passed through.
.PP
For libguestfs tools, use the \fI\-\-format\fR command line parameter as
appropriate.
.SS "\s-1CVE\-2011\-4127\s0"
.IX Subsection "CVE-2011-4127"
https://bugzilla.redhat.com/752375
.PP
This is a bug in the kernel which allowed guests to overwrite parts of the
host's drives which they should not normally have access to.
.PP
It is sufficient to update libguestfs to any version ≥ 1.16 which
contains a change that mitigates the problem.
.SS "\s-1CVE\-2012\-2690\s0"
.IX Subsection "CVE-2012-2690"
https://bugzilla.redhat.com/831117
.PP
Old versions of both virt-edit and the guestfish \f(CW\*(C`edit\*(C'\fR command created a
new file containing the changes but did not set the permissions, etc of the
new file to match the old one.  The result of this was that if you edited a
security sensitive file such as \fI/etc/shadow\fR then it would be left
world-readable after the edit.
.PP
It is sufficient to update libguestfs to any version ≥ 1.16.
.SS "\s-1CVE\-2013\-2124\s0"
.IX Subsection "CVE-2013-2124"
https://bugzilla.redhat.com/968306
.PP
This security bug was a flaw in inspection where an untrusted guest using a
specially crafted file in the guest \s-1OS\s0 could cause a double-free in the C
library (denial of service).
.PP
It is sufficient to update libguestfs to a version that is not vulnerable:
libguestfs ≥ 1.20.8, ≥ 1.22.2 or ≥ 1.23.2.
.SS "\s-1CVE\-2013\-4419\s0"
.IX Subsection "CVE-2013-4419"
https://bugzilla.redhat.com/1016960
.PP
When using the \fIguestfish\fR\|(1) \fI\-\-remote\fR or guestfish \fI\-\-listen\fR options,
guestfish would create a socket in a known location
(\fI/tmp/.guestfish\-$UID/socket\-$PID\fR).
.PP
The location has to be a known one in order for both ends to communicate.
However no checking was done that the containing directory
(\fI/tmp/.guestfish\-$UID\fR) is owned by the user.  Thus another user could
create this directory and potentially hijack sockets owned by another user's
guestfish client or server.
.PP
It is sufficient to update libguestfs to a version that is not vulnerable:
libguestfs ≥ 1.20.12, ≥ 1.22.7 or ≥ 1.24.
.SS "Denial of service when inspecting disk images with corrupt btrfs volumes"
.IX Subsection "Denial of service when inspecting disk images with corrupt btrfs volumes"
It was possible to crash libguestfs (and programs that use libguestfs as a
library) by presenting a disk image containing a corrupt btrfs volume.
.PP
This was caused by a \s-1NULL\s0 pointer dereference causing a denial of service,
and is not thought to be exploitable any further.
.PP
See commit d70ceb4cbea165c960710576efac5a5716055486 for the fix.  This fix
is included in libguestfs stable branches ≥ 1.26.0, ≥ 1.24.6
and ≥ 1.22.8, and also in \s-1RHEL\s0 ≥ 7.0.  Earlier versions of
libguestfs are not vulnerable.
.SS "\s-1CVE\-2014\-0191\s0"
.IX Subsection "CVE-2014-0191"
Libguestfs previously used unsafe libxml2 APIs for parsing libvirt \s-1XML.\s0
These APIs defaulted to allowing network connections to be made when certain
\&\s-1XML\s0 documents were presented.  Using a malformed \s-1XML\s0 document it was also
possible to exhaust all \s-1CPU,\s0 memory or file descriptors on the machine.
.PP
Since the libvirt \s-1XML\s0 comes from a trusted source (the libvirt daemon)  it
is not thought that this could have been exploitable.
.PP
This was fixed in libguestfs ≥ 1.27.9 and the fix was backported to
stable versions ≥ 1.26.2, ≥ 1.24.9, ≥ 1.22.10 and ≥ 1.20.13.
.SS "Shellshock (bash \s-1CVE\-2014\-6271\s0)"
.IX Subsection "Shellshock (bash CVE-2014-6271)"
This bash bug indirectly affects libguestfs.  For more information see:
https://www.redhat.com/archives/libguestfs/2014\-September/msg00252.html
.SS "\s-1CVE\-2014\-8484\s0"
.IX Subsection "CVE-2014-8484"
.SS "\s-1CVE\-2014\-8485\s0"
.IX Subsection "CVE-2014-8485"
These two bugs in binutils affect the \s-1GNU \s0\fIstrings\fR\|(1) program, and thus
the \*(L"guestfs_strings\*(R" in \fIguestfs\fR\|(3) and \*(L"guestfs_strings_e\*(R" in \fIguestfs\fR\|(3) APIs
in libguestfs.  Running strings on an untrusted file could cause arbitrary
code execution (confined to the libguestfs appliance).
.PP
In libguestfs ≥ 1.29.5 and ≥ 1.28.3, libguestfs uses the \f(CW\*(C`strings\*(C'\fR
\&\fI\-a\fR option to avoid \s-1BFD\s0 parsing on the file.
.SS "\s-1CVE\-2015\-5745\s0"
.IX Subsection "CVE-2015-5745"
https://bugzilla.redhat.com/show_bug.cgi?id=1251157
.PP
This is not a vulnerability in libguestfs, but because we always give a
virtio-serial port to each guest (since that is how guest-host communication
happens), an escalation from the appliance to the host qemu process is
possible.  This could affect you if:
.IP "\(bu" 4
your libguestfs program runs untrusted programs out of the guest (using
\&\*(L"guestfs_sh\*(R" in \fIguestfs\fR\|(3) etc), or
.IP "\(bu" 4
another exploit was found in (for example) kernel filesystem code that
allowed a malformed filesystem to take over the appliance.
.PP
If you use sVirt to confine qemu, that would thwart some attacks.
.SS "Permissions of \fI.ssh\fP and \fI.ssh/authorized_keys\fP"
.IX Subsection "Permissions of .ssh and .ssh/authorized_keys"
https://bugzilla.redhat.com/1260778
.PP
The tools \fIvirt\-customize\fR\|(1), \fIvirt\-sysprep\fR\|(1) and \fIvirt\-builder\fR\|(1)
have an \fI\-\-ssh\-inject\fR option for injecting an \s-1SSH\s0 key into virtual machine
disk images.  They may create a \fI~user/.ssh\fR directory and
\&\fI~user/.ssh/authorized_keys\fR file in the guest to do this.
.PP
In libguestfs < 1.31.5 and libguestfs < 1.30.2, the new directory
and file would get mode \f(CW0755\fR and mode \f(CW0644\fR respectively.  However
these permissions (especially for \fI~user/.ssh\fR) are wider than the
permissions that OpenSSH uses.  In current libguestfs, the directory and
file are created with mode \f(CW0700\fR and mode \f(CW0600\fR.
.SS "\s-1CVE\-2015\-8869\s0"
.IX Subsection "CVE-2015-8869"
https://bugzilla.redhat.com/CVE\-2015\-8869
.PP
This vulnerability in OCaml might affect virt tools written in the OCaml
programming language.  It affects only 64 bit platforms.  Because this bug
affects code generation it is difficult to predict which precise software
could be affected, and therefore our recommendation is that you recompile
libguestfs using a version of the OCaml compiler where this bug has been
fixed (or ask your Linux distro to do the same).
.SH "関連項目"
.IX Header "関連項目"
\&\fIguestfs\fR\|(3), \fIguestfs\-internals\fR\|(3), \fIguestfs\-release\-notes\fR\|(1),
\&\fIguestfs\-testing\fR\|(1), http://libguestfs.org/.
.SH "著者"
.IX Header "著者"
Richard W.M. Jones (\f(CW\*(C`rjones at redhat dot com\*(C'\fR)
.SH "COPYRIGHT"
.IX Header "COPYRIGHT"
Copyright (C) 2009\-2016 Red Hat Inc.
.SH "LICENSE"
.IX Header "LICENSE"
.SH "BUGS"
.IX Header "BUGS"
To get a list of bugs against libguestfs, use this link:
https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools
.PP
To report a new bug against libguestfs, use this link:
https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools
.PP
When reporting a bug, please supply:
.IP "\(bu" 4
The version of libguestfs.
.IP "\(bu" 4
Where you got libguestfs (eg. which Linux distro, compiled from source, etc)
.IP "\(bu" 4
Describe the bug accurately and give a way to reproduce it.
.IP "\(bu" 4
Run \fIlibguestfs\-test\-tool\fR\|(1) and paste the \fBcomplete, unedited\fR
output into the bug report.