1guestfs-security(1)         Virtualization Support         guestfs-security(1)
2
3
4

NAME

6       guestfs-security - security of libguestfs
7

DESCRIPTION

9       This manual page discusses security implications of using libguestfs,
10       particularly with untrusted or malicious guests or disk images.
11

REPORTING SECURITY PROBLEMS

13       If you wish to privately report a security issue, please follow the Red
14       Hat security procedure at
15       https://access.redhat.com/security/team/contact
16
17       If the security problem is not so serious, you can simply file a bug
18       (see "BUGS" below), or send an email to our mailing list
19       (https://lists.libguestfs.org).  You do not need to subscribe to the
20       mailing list to send email, but there will be a delay while the message
21       is moderated.
22

GENERAL ISSUES

24   Security of mounting filesystems
25       You should never mount an untrusted guest filesystem directly on your
26       host kernel (eg. using loopback or kpartx).
27
28       When you mount a filesystem, mistakes in the kernel filesystem (VFS)
29       can be escalated into exploits by attackers creating a malicious
30       filesystem.  These exploits are very severe for two reasons.  Firstly
31       there are very many filesystem drivers in the kernel, and many of them
32       are infrequently used and not much developer attention has been paid to
33       the code.  Linux userspace helps potential crackers by detecting the
34       filesystem type and automatically choosing the right VFS driver, even
35       if that filesystem type is unexpected.  Secondly, a kernel-level
36       exploit is like a local root exploit (worse in some ways), giving
37       immediate and total access to the system right down to the hardware
38       level.
39
40       These exploits can be present in the kernel for a very long time
41       (https://lwn.net/Articles/538898/).
42
43       Libguestfs provides a layered approach to protecting you from exploits:
44
45          untrusted filesystem
46        --------------------------------------
47          appliance kernel
48        --------------------------------------
49          qemu process running as non-root
50        --------------------------------------
51          sVirt [if using libvirt + SELinux]
52        --------------------------------------
53          host kernel
54
55       We run a Linux kernel inside a qemu virtual machine, usually running as
56       a non-root user.  The attacker would need to write a filesystem which
57       first exploited the kernel, and then exploited either qemu
58       virtualization (eg. a faulty qemu driver) or the libguestfs protocol,
59       and finally to be as serious as the host kernel exploit it would need
60       to escalate its privileges to root.  Additionally if you use the
61       libvirt back end and SELinux, sVirt is used to confine the qemu
62       process.  This multi-step escalation, performed by a static piece of
63       data, is thought to be extremely hard to do, although we never say
64       ‘never’ about security issues.
65
66       Callers can also reduce the attack surface by forcing the filesystem
67       type when mounting (use "guestfs_mount_vfs" in guestfs(3)).
68
69   General security considerations
70       Be careful with any files or data that you download from a guest (by
71       "download" we mean not just the "guestfs_download" in guestfs(3)
72       command but any command that reads files, filenames, directories or
73       anything else from a disk image).  An attacker could manipulate the
74       data to fool your program into doing the wrong thing.  Consider cases
75       such as:
76
77       •   the data (file etc) not being present
78
79       •   being present but empty
80
81       •   being much larger than normal
82
83       •   containing arbitrary 8 bit data
84
85       •   being in an unexpected character encoding
86
87       •   containing homoglyphs.
88
89   Protocol security
90       The protocol is designed to be secure, being based on RFC 4506 (XDR)
91       with a defined upper message size.  However a program that uses
92       libguestfs must also take care - for example you can write a program
93       that downloads a binary from a disk image and executes it locally, and
94       no amount of protocol security will save you from the consequences.
95
96   Inspection security
97       Parts of the inspection API (see "INSPECTION" in guestfs(3)) return
98       untrusted strings directly from the guest, and these could contain any
99       8 bit data.  Callers should be careful to escape these before printing
100       them to a structured file (for example, use HTML escaping if creating a
101       web page).
102
103       Guest configuration may be altered in unusual ways by the administrator
104       of the virtual machine, and may not reflect reality (particularly for
105       untrusted or actively malicious guests).  For example we parse the
106       hostname from configuration files like /etc/sysconfig/network that we
107       find in the guest, but the guest administrator can easily manipulate
108       these files to provide the wrong hostname.
109
110       The inspection API parses guest configuration using two external
111       libraries: Augeas (Linux configuration) and hivex (Windows Registry).
112       Both are designed to be robust in the face of malicious data, although
113       denial of service attacks are still possible, for example with
114       oversized configuration files.
115
116   Running untrusted guest commands
117       Be very cautious about running commands from the guest.  By running a
118       command in the guest, you are giving CPU time to a binary that you do
119       not control, under the same user account as the library, albeit wrapped
120       in qemu virtualization.  More information and alternatives can be found
121       in "RUNNING COMMANDS" in guestfs(3).
122

HISTORICAL SECURITY ISSUES IN LIBGUESTFS

124   CVE-2010-3851
125       https://bugzilla.redhat.com/642934
126
127       This security bug concerns the automatic disk format detection that
128       qemu does on disk images.
129
130       A raw disk image is just the raw bytes, there is no header.  Other disk
131       images like qcow2 contain a special header.  Qemu deals with this by
132       looking for one of the known headers, and if none is found then
133       assuming the disk image must be raw.
134
135       This allows a guest which has been given a raw disk image to write some
136       other header.  At next boot (or when the disk image is accessed by
137       libguestfs) qemu would do autodetection and think the disk image format
138       was, say, qcow2 based on the header written by the guest.
139
140       This in itself would not be a problem, but qcow2 offers many features,
141       one of which is to allow a disk image to refer to another image (called
142       the "backing disk").  It does this by placing the path to the backing
143       disk into the qcow2 header.  This path is not validated and could point
144       to any host file (eg. "/etc/passwd").  The backing disk is then exposed
145       through "holes" in the qcow2 disk image, which of course is completely
146       under the control of the attacker.
147
148       In libguestfs this is rather hard to exploit except under two
149       circumstances:
150
151       1.  You have enabled the network or have opened the disk in write mode.
152
153       2.  You are also running untrusted code from the guest (see "RUNNING
154           COMMANDS" in guestfs(3)).
155
156       The way to avoid this is to specify the expected disk format when
157       adding disks (the optional "format" option to "guestfs_add_drive_opts"
158       in guestfs(3)).  You should always do this if the disk is raw format,
159       and it’s a good idea for other cases too.  (See also "DISK IMAGE
160       FORMATS" in guestfs(3)).
161
162       For disks added from libvirt using calls like "guestfs_add_domain" in
163       guestfs(3), the format is fetched from libvirt and passed through.
164
165       For libguestfs tools, use the --format command line parameter as
166       appropriate.
167
168   CVE-2011-4127
169       https://bugzilla.redhat.com/752375
170
171       This is a bug in the kernel which allowed guests to overwrite parts of
172       the host’s drives which they should not normally have access to.
173
174       It is sufficient to update libguestfs to any version ≥ 1.16 which
175       contains a change that mitigates the problem.
176
177   CVE-2012-2690
178       https://bugzilla.redhat.com/831117
179
180       Old versions of both virt-edit and the guestfish "edit" command created
181       a new file containing the changes but did not set the permissions, etc
182       of the new file to match the old one.  The result of this was that if
183       you edited a security sensitive file such as /etc/shadow then it would
184       be left world-readable after the edit.
185
186       It is sufficient to update libguestfs to any version ≥ 1.16.
187
188   CVE-2013-2124
189       https://bugzilla.redhat.com/968306
190
191       This security bug was a flaw in inspection where an untrusted guest
192       using a specially crafted file in the guest OS could cause a double-
193       free in the C library (denial of service).
194
195       It is sufficient to update libguestfs to a version that is not
196       vulnerable: libguestfs ≥ 1.20.8, ≥ 1.22.2 or ≥ 1.23.2.
197
198   CVE-2013-4419
199       https://bugzilla.redhat.com/1016960
200
201       When using the guestfish(1) --remote or guestfish --listen options,
202       guestfish would create a socket in a known location
203       (/tmp/.guestfish-$UID/socket-$PID).
204
205       The location has to be a known one in order for both ends to
206       communicate.  However no checking was done that the containing
207       directory (/tmp/.guestfish-$UID) is owned by the user.  Thus another
208       user could create this directory and potentially hijack sockets owned
209       by another user’s guestfish client or server.
210
211       It is sufficient to update libguestfs to a version that is not
212       vulnerable: libguestfs ≥ 1.20.12, ≥ 1.22.7 or ≥ 1.24.
213
214   Denial of service when inspecting disk images with corrupt btrfs volumes
215       It was possible to crash libguestfs (and programs that use libguestfs
216       as a library) by presenting a disk image containing a corrupt btrfs
217       volume.
218
219       This was caused by a NULL pointer dereference causing a denial of
220       service, and is not thought to be exploitable any further.
221
222       See commit d70ceb4cbea165c960710576efac5a5716055486 for the fix.  This
223       fix is included in libguestfs stable branches ≥ 1.26.0, ≥ 1.24.6 and
224       ≥ 1.22.8, and also in RHEL ≥ 7.0.  Earlier versions of libguestfs are
225       not vulnerable.
226
227   CVE-2014-0191
228       Libguestfs previously used unsafe libxml2 APIs for parsing libvirt XML.
229       These APIs defaulted to allowing network connections to be made when
230       certain XML documents were presented.  Using a malformed XML document
231       it was also possible to exhaust all CPU, memory or file descriptors on
232       the machine.
233
234       Since the libvirt XML comes from a trusted source (the libvirt daemon)
235       it is not thought that this could have been exploitable.
236
237       This was fixed in libguestfs ≥ 1.27.9 and the fix was backported to
238       stable versions ≥ 1.26.2, ≥ 1.24.9, ≥ 1.22.10 and ≥ 1.20.13.
239
240   Shellshock (bash CVE-2014-6271)
241       This bash bug indirectly affects libguestfs.  For more information see:
242       https://www.redhat.com/archives/libguestfs/2014-September/msg00252.html
243
244   CVE-2014-8484
245   CVE-2014-8485
246       These two bugs in binutils affect the GNU strings(1) program, and thus
247       the "guestfs_strings" in guestfs(3) and "guestfs_strings_e" in
248       guestfs(3) APIs in libguestfs.  Running strings on an untrusted file
249       could cause arbitrary code execution (confined to the libguestfs
250       appliance).
251
252       In libguestfs ≥ 1.29.5 and ≥ 1.28.3, libguestfs uses the "strings" -a
253       option to avoid BFD parsing on the file.
254
255   CVE-2015-5745
256       https://bugzilla.redhat.com/show_bug.cgi?id=1251157
257
258       This is not a vulnerability in libguestfs, but because we always give a
259       virtio-serial port to each guest (since that is how guest-host
260       communication happens), an escalation from the appliance to the host
261       qemu process is possible.  This could affect you if:
262
263       •   your libguestfs program runs untrusted programs out of the guest
264           (using "guestfs_sh" in guestfs(3) etc), or
265
266       •   another exploit was found in (for example) kernel filesystem code
267           that allowed a malformed filesystem to take over the appliance.
268
269       If you use sVirt to confine qemu, that would thwart some attacks.
270
271   Permissions of .ssh and .ssh/authorized_keys
272       https://bugzilla.redhat.com/1260778
273
274       The tools virt-customize(1), virt-sysprep(1) and virt-builder(1) have
275       an --ssh-inject option for injecting an SSH key into virtual machine
276       disk images.  They may create a ~user/.ssh directory and
277       ~user/.ssh/authorized_keys file in the guest to do this.
278
279       In libguestfs < 1.31.5 and libguestfs < 1.30.2, the new directory and
280       file would get mode 0755 and mode 0644 respectively.  However these
281       permissions (especially for ~user/.ssh) are wider than the permissions
282       that OpenSSH uses.  In current libguestfs, the directory and file are
283       created with mode 0700 and mode 0600.
284
285   CVE-2015-8869
286       https://bugzilla.redhat.com/CVE-2015-8869
287
288       This vulnerability in OCaml might affect virt tools written in the
289       OCaml programming language.  It affects only 64 bit platforms.  Because
290       this bug affects code generation it is difficult to predict which
291       precise software could be affected, and therefore our recommendation is
292       that you recompile libguestfs using a version of the OCaml compiler
293       where this bug has been fixed (or ask your Linux distro to do the
294       same).
295
296   CVE-2017-5208, CVE-2017-5331, CVE-2017-5332, CVE-2017-5333, CVE-2017-6009,
297       CVE-2017-6010, CVE-2017-6011
298       Multiple vulnerabilities in the wrestool(1) program in the "icoutils"
299       package can be exploited for local code execution on the host.
300
301       When libguestfs inspection (see "Inspection security" above) detects a
302       Windows XP or Windows 7 guest and is asked to find an associated icon
303       for the guest, it will download an untrusted file from the guest and
304       run "wrestool -x" on that file.  This can lead to local code execution
305       on the host.  Any disk image or guest can be crafted to look like a
306       Windows guest to libguestfs inspection, so just because you do not have
307       Windows guests does not help.
308
309       Any program calling the libguestfs API "guestfs_inspect_get_icon" could
310       be vulnerable.  This includes virt-inspector(1) and virt-manager(1).
311
312       The solution is to update to the non-vulnerable version of icoutils (at
313       least 0.31.1).
314
315   CVE-2017-7244, CVE-2017-7245, CVE-2017-7246
316       Multiple vulnerabilities in PCRE could be exploited to crash libguestfs
317       (ie. cause a denial of service) when performing inspection on an
318       untrusted virtual machine.
319
320       The solution is to update to a version of PCRE with these bugs fixed
321       (upstream version ≥ 8.41).
322
323   CVE-2018-11806
324       Vulnerabilities affecting qemu user networking (SLIRP) allow a
325       malicious filesystem image to take control of qemu and from there
326       attack the host.
327
328       This affects libguestfs when the backend is set to "direct" and
329       networking is enabled.
330
331       The direct backend is the default upstream, but not in some downstream
332       Linux distributions including Fedora, Red Hat Enterprise Linux and
333       CentOS.  It might also have been selected if you set the
334       "LIBGUESTFS_BACKEND=direct" environment variable or called
335       "guestfs_set_backend (g, "direct")".
336
337       Networking is enabled automatically by some tools (eg.
338       virt-builder(1)), or is enabled if your code called
339       "guestfs_set_network (g, 1)" (which is not the default).
340
341       The libvirt backend is not affected.
342
343       The solution is to update qemu to a version containing the fix (see
344       https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg01012.html).
345
346   CVE-2022-2211
347       https://bugzilla.redhat.com/CVE-2022-2211
348
349       The "get_keys" function in libguestfs-common/options/keys.c collects
350       those --key options from the command line into a new array that match a
351       particular block device that's being decrypted for inspection. The
352       function intends to size the result array such that potentially all
353       --key options, plus a terminating "NULL" element, fit into it. The code
354       mistakenly uses the "MIN" macro instead of "MAX", and therefore only
355       one element is allocated before the "NULL" terminator.
356
357       Passing precisely two --key ID:... options on the command line for the
358       encrypted block device "ID" causes "get_keys" to overwrite the
359       terminating "NULL", leading to an out-of-bounds read in
360       "decrypt_mountables", file libguestfs-common/options/decrypt.c.
361
362       Passing more than two --key ID:... options on the command line for the
363       encrypted block device "ID" causes "get_keys" itself to perform out-of-
364       bounds writes. The most common symptom is a crash with "SIGSEGV" later
365       on.
366
367       This issue affects -- broadly speaking -- all libguestfs-based
368       utilities that accept --key, namely: "guestfish", "guestmount",
369       "virt-cat", "virt-customize", "virt-diff", "virt-edit",
370       "virt-get-kernel", "virt-inspector", "virt-log", "virt-ls",
371       "virt-sparsify", "virt-sysprep", "virt-tail", "virt-v2v".
372

SEE ALSO

374       guestfs(3), guestfs-internals(1), guestfs-release-notes(1),
375       guestfs-testing(1), http://libguestfs.org/.
376

AUTHORS

378       Richard W.M. Jones ("rjones at redhat dot com")
379
381       Copyright (C) 2009-2023 Red Hat Inc.
382

LICENSE

384       This library is free software; you can redistribute it and/or modify it
385       under the terms of the GNU Lesser General Public License as published
386       by the Free Software Foundation; either version 2 of the License, or
387       (at your option) any later version.
388
389       This library is distributed in the hope that it will be useful, but
390       WITHOUT ANY WARRANTY; without even the implied warranty of
391       MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
392       Lesser General Public License for more details.
393
394       You should have received a copy of the GNU Lesser General Public
395       License along with this library; if not, write to the Free Software
396       Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
397       02110-1301 USA
398

BUGS

400       To get a list of bugs against libguestfs, use this link:
401       https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools
402
403       To report a new bug against libguestfs, use this link:
404       https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools
405
406       When reporting a bug, please supply:
407
408       •   The version of libguestfs.
409
410       •   Where you got libguestfs (eg. which Linux distro, compiled from
411           source, etc)
412
413       •   Describe the bug accurately and give a way to reproduce it.
414
415       •   Run libguestfs-test-tool(1) and paste the complete, unedited output
416           into the bug report.
417
418
419
420libguestfs-1.51.9                 2023-12-09               guestfs-security(1)
Impressum