1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
|
Empty password allows access to VNC in libvirt
The help in the /etc/libvirt/qemu.conf states
"To allow access without passwords, leave this commented out. An empty
string will still enable passwords, but be rejected by QEMU
effectively preventing any use of VNC."
yet setting:
vnc_password=""
allows access to the vnc console without any password prompt just as if it is hashed out completely.
ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: libvirt-bin 0.8.3-1ubuntu14
ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8
Uname: Linux 2.6.35-24-server x86_64
Architecture: amd64
Date: Tue Jan 4 12:18:35 2011
InstallationMedia: Ubuntu-Server 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.2)
ProcEnviron:
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: libvirt
Thanks for taking the time to report this bug and helping to make Ubuntu better.
The feature itself may be low priority, bug getting the comment in the qemu.conf file fixed so that no admins get caught by surprise seems like high priority. I see no activity in the upstream bug yet, though, so will wait to see what feedback happens there.
From the libvirt list
"The behaviour you're seeing is a bug recently introduced in
> the QEMU monitor password command handling by QEMU GIT repo
> changeset 52c18be9e99dabe295321153fda7fce9f76647ac.
> "
On 7 January 2011 14:41, Serge Hallyn <email address hidden> wrote:
> ** Changed in: libvirt (Ubuntu)
> Assignee: (unassigned) => Serge Hallyn (serge-hallyn)
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/697197
>
> Title:
> Empty password allows access to VNC in libvirt
>
--
Neil Wilson
Libvirt is in the clear on this one. It is a mild security issue introduced into QEMU.
When I say in the clear, the libvirt guys think they're in the clear.
Checked the qemu source and there is no fix for this problem. Could be a change of behaviour.
CVE issued putting the onus squarely on qemu's shoulders.
The solution to this problem is to reverse the commit 52c18be9e99dabe295321153fda7fce9f76647ac in the main Qemu archive.
Installed patched build onto Maverick server. vnc_listen set to 0.0.0.0 in /etc/libvirt/qemu.conf
Set vnc_password=""' with vnc_tls=1 in /etc/libvirt/qemu.conf and confirmed that the lanched server now rejects authentication for any password, whereas it turned off authentication and encryption completely before.
Hashed out vnc_password and left vnc_tls=1 in /etc/libvirt/qemu.conf. Confirmed that the server uses anonymous auth with TLS. Allows the user on without a password. qemu-kvm launched with -vnc 0.0.0.0:0,tls,x509=/etc/pki/libvirt-vnc
Hashed out vnc_tls=1. Confirmed server allows direct access to VNC. qemu-kvm launched with -vnc 0.0.0.0:0
Set vnc_password="". Confirmed server rejects authentication for any password, with no encryption. Again previously it had just let the user on. qemu-kvm launched with -vnc 0.0.0.0:0,password
set vnc_password="password". Confirmed server accepts authentication with that password. qemu-kvm launched with -vnc 0.0.0.0:0,password
Please sponsor for upload
This fault probably affects all the current versions of qemu-kvm. It's present in 0.11 and the current qemu master branch.
Looks good, thanks for doing this, Neil.
I'm going to update it just slightly, as this debdiff will need to go through the security queue, since there's an associated CVE. I'll prep that upload and the security team will sponsor it into maverick-security.
I'll get it uploaded to natty now.
The last thing I need you to do is to email your patch to the qemu-devel mailing list. The maintainers do not accept patches solely attached to bugs in Launchpad. Their processes require that you email the patch to the mailing list. Sorry for the run-around. Cheers!
@security team,
Could you please sponsor this to the maverick-security queue? Thanks!
The patch needs to go into Lucid as well.
Marking the libvirt tasks "invalid", as upstream libvirt has correctly pointed out that this bug is in qemu, and not libvirt:
* https://bugzilla.redhat.com/show_bug.cgi?id=667097
Uploading to Natty now...
Confirmed that the affected code is also in Lucid. Adding a task for that, and attaching a debdiff for lucid-security too.
This bug was fixed in the package qemu-kvm - 0.13.0+noroms-0ubuntu13
---------------
qemu-kvm (0.13.0+noroms-0ubuntu13) natty; urgency=low
[ Neil Wilson <email address hidden> ]
* SECURITY UPDATE: Setting VNC password to empty string silently
disables all authentication (LP: #697197)
- debian/patches/697197-fix-vnc-password-semantics.patch: Reverses the
change introduced in Qemu by git commit 52c18be9
- CVE: 2011-0011
[ Dustin Kirkland ]
* Updated patch to reflect the move of vnc.c to ui/vnc.c
-- Dustin Kirkland <email address hidden> Fri, 11 Feb 2011 09:53:19 -0600
Attaching Lucid debdiff.
Thanks for preparing the debdiffs! It looks like karmic is vulnerable too, so we'll need that as well. I'll update the debdiffs to use proper DEP-3 and fix up the formatting of the changelogs a bit ("CVE-" vs "CVE: "), and get these building.
Attaching debdiff for karmic.
This bug was fixed in the package qemu-kvm - 0.12.5+noroms-0ubuntu7.2
---------------
qemu-kvm (0.12.5+noroms-0ubuntu7.2) maverick-security; urgency=low
[ Dustin Kirkland ]
* SECURITY UPDATE: Setting VNC password to empty string silently
disables all authentication (LP: #697197).
- debian/patches/697197-fix-vnc-password-semantics.patch: Reverses the
change introduced in Qemu by git commit 52c18be9, thanks to Neil Wilson.
- CVE-2011-0011
[ Kees Cook ]
* debian/rules: disable parallel build; fix FTBFS.
-- Kees Cook <email address hidden> Fri, 11 Feb 2011 15:52:12 -0800
This bug was fixed in the package qemu-kvm - 0.12.3+noroms-0ubuntu9.4
---------------
qemu-kvm (0.12.3+noroms-0ubuntu9.4) lucid-security; urgency=low
* SECURITY UPDATE: Setting VNC password to empty string silently
disables all authentication (LP: #697197)
- debian/patches/697197-fix-vnc-password-semantics.patch: Reverses the
change introduced in Qemu by git commit 52c18be9, thanks to Neil Wilson.
- CVE-2011-0011
-- Dustin Kirkland <email address hidden> Fri, 11 Feb 2011 09:57:30 -0600
This bug was fixed in the package qemu-kvm - 0.11.0-0ubuntu6.4
---------------
qemu-kvm (0.11.0-0ubuntu6.4) karmic-security; urgency=low
* SECURITY UPDATE: Setting VNC password to empty string silently
disables all authentication (LP: #697197)
- debian/patches/697197-fix-vnc-password-semantics.patch: Reverses the
change introduced in Qemu by git commit 52c18be9, thanks to Neil Wilson.
- CVE-2011-0011
-- Dustin Kirkland <email address hidden> Fri, 11 Feb 2011 17:46:26 -0600
Nothing left to do, unsubscribing ubuntu-security-sponsors.
Ubuntu 12.04 is also affected
Description of problem:
The help for 'vnc_password' in qemu.conf states "An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC.".
Yet if you set vnc_password="" then you can access the VNC console without any password prompt at all - just as you can if the entry is hashed out.
Version-Release number of selected component (if applicable):
libvirtd (libvirt) 0.8.3
How reproducible:
Every time by configuration
Steps to Reproduce:
1. Create a VNC console without a password.
2. Set vnc_password="" in /etc/libvirt/qemu.conf
3. Start up a guest and access the VNC console with a client.
Actual results:
You get straight into the console with no prompts.
Expected results:
Should have come up with a prompt and rejected the access. Or the instructions in the qemu.conf file need changing to take account of the current behaviour.
Additional info:
Similarly if you set the passwd attribute to '' in the vnc graphics XML stanza.
This is not a libvirt bug. This is caused by a flaw in particular QEMU version you are using, which silently disables auth when the password is set to "". This bug was introduced in QEMU in this bogus commit
commit 52c18be9e99dabe295321153fda7fce9f76647ac
Author: Zachary Amsden <email address hidden>
Date: Thu Jul 30 00:15:01 2009 -1000
When using stdio monitor and VNC display, one can set or clear a VNC password; this should set or turn off VNC authentication as well.
Description of problem:
The semantics of the ',password' option to -vnc are that it enables the VNC auth scheme. If the VNC server password is unset or empty string, all attempts to authenticate with the server will be explicitly blocked.
This allows applications to enable and selectively allow access for a period of time, before clearing the password again to prevent further access.
Upstream changes have introduced a flaw by disabling all authentication when the password was cleared with upstream commit [1].
[1] http://www.qemu.com/qemu.git/commit/?id=52c18be9e99dabe295321153fda7fce9f76647ac
Created attachment 475841
Fix to vnc password semantics
This patch corrects the flaw in qemu-kvm
Please see http://launchpad.net/bugs/697197 for testing performed.
Created qemu tracking bugs for this issue
Affects: fedora-all [bug 680886]
This issue has been addressed in following products:
Red Hat Enterprise Linux 6
Via RHSA-2011:0345 https://rhn.redhat.com/errata/RHSA-2011-0345.html
Statement:
This issue does not affect versions of kvm package as shipped with Red Hat Enterprise Linux 5.
|