1guestfs-security(1) Virtualization Support guestfs-security(1)
2
6 guestfs-security - security of libguestfs
7
9 This manual page discusses security implications of using libguestfs,
10 particularly with untrusted or malicious guests or disk images.
11
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 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
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 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 These exploits can be present in the kernel for a very long time
41 (https://lwn.net/Articles/538898/).
42 Libguestfs provides a layered approach to protecting you from exploits:
44 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 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 Callers can also reduce the attack surface by forcing the filesystem
67 type when mounting (use "guestfs_mount_vfs" in guestfs(3)).
68 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 • the data (file etc) not being present
78 • being present but empty
80 • being much larger than normal
82 • containing arbitrary 8 bit data
84 • being in an unexpected character encoding
86 • containing homoglyphs.
88 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 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 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 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 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
124 CVE-2010-3851
125 https://bugzilla.redhat.com/642934
126 This security bug concerns the automatic disk format detection that
128 qemu does on disk images.
129 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 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 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 In libguestfs this is rather hard to exploit except under two
149 circumstances:
150 1. You have enabled the network or have opened the disk in write mode.
152 2. You are also running untrusted code from the guest (see "RUNNING
154 COMMANDS" in guestfs(3)).
155 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 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 For libguestfs tools, use the --format command line parameter as
166 appropriate.
167 CVE-2011-4127
169 https://bugzilla.redhat.com/752375
170 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 It is sufficient to update libguestfs to any version ≥ 1.16 which
175 contains a change that mitigates the problem.
176 CVE-2012-2690
178 https://bugzilla.redhat.com/831117
179 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 It is sufficient to update libguestfs to any version ≥ 1.16.
187 CVE-2013-2124
189 https://bugzilla.redhat.com/968306
190 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 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 CVE-2013-4419
199 https://bugzilla.redhat.com/1016960
200 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 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 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 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 This was caused by a NULL pointer dereference causing a denial of
220 service, and is not thought to be exploitable any further.
221 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 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 Since the libvirt XML comes from a trusted source (the libvirt daemon)
235 it is not thought that this could have been exploitable.
236 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 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 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 In libguestfs ≥ 1.29.5 and ≥ 1.28.3, libguestfs uses the "strings" -a
253 option to avoid BFD parsing on the file.
254 CVE-2015-5745
256 https://bugzilla.redhat.com/show_bug.cgi?id=1251157
257 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 • your libguestfs program runs untrusted programs out of the guest
264 (using "guestfs_sh" in guestfs(3) etc), or
265 • another exploit was found in (for example) kernel filesystem code
267 that allowed a malformed filesystem to take over the appliance.
268 If you use sVirt to confine qemu, that would thwart some attacks.
270 Permissions of .ssh and .ssh/authorized_keys
272 https://bugzilla.redhat.com/1260778
273 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 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 CVE-2015-8869
286 https://bugzilla.redhat.com/CVE-2015-8869
287 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 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 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 Any program calling the libguestfs API "guestfs_inspect_get_icon" could
310 be vulnerable. This includes virt-inspector(1) and virt-manager(1).
311 The solution is to update to the non-vulnerable version of icoutils (at
313 least 0.31.1).
314 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 The solution is to update to a version of PCRE with these bugs fixed
321 (upstream version ≥ 8.41).
322 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 This affects libguestfs when the backend is set to "direct" and
329 networking is enabled.
330 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 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 The libvirt backend is not affected.
342 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 CVE-2022-2211
347 https://bugzilla.redhat.com/CVE-2022-2211
348 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 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 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 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
374 guestfs(3), guestfs-internals(1), guestfs-release-notes(1),
375 guestfs-testing(1), http://libguestfs.org/.
376
378 Richard W.M. Jones ("rjones at redhat dot com")
379
381 Copyright (C) 2009-2023 Red Hat Inc.
382
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 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 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
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 To report a new bug against libguestfs, use this link:
404 https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools
405 When reporting a bug, please supply:
407 • The version of libguestfs.
409 • Where you got libguestfs (eg. which Linux distro, compiled from
411 source, etc)
412 • Describe the bug accurately and give a way to reproduce it.
414 • Run libguestfs-test-tool(1) and paste the complete, unedited output
416 into the bug report.
417libguestfs-1.51.9 2023-12-09 guestfs-security(1)