Bug 1026879 - Strict passwd checking not implemented during VNC authentication
Strict passwd checking not implemented during VNC authentication
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda (Show other bugs)
7.0
ppc64 All
unspecified Severity medium
: rc
: 7.0
Assigned To: Vratislav Podzimek
Release Test Team
: Patch, Reopened
: 1080641 (view as bug list)
Depends On:
Blocks: 744225
  Show dependency treegraph
 
Reported: 2013-11-05 10:10 EST by IBM Bug Proxy
Modified: 2014-06-17 21:42 EDT (History)
14 users (show)

See Also:
Fixed In Version: anaconda-19.31.42-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1056939 (view as bug list)
Environment:
Last Closed: 2014-06-13 07:16:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
anaconda.log SNAP10 (29.40 KB, text/x-log)
2014-03-26 06:17 EDT, IBM Bug Proxy
no flags Details
anaconda.program.log SNAP10 (34.55 KB, text/x-log)
2014-03-26 06:17 EDT, IBM Bug Proxy
no flags Details
anaconda.ifcfg.log SNAP10 (2.06 KB, text/x-log)
2014-03-26 06:17 EDT, IBM Bug Proxy
no flags Details
anaconda.storage.log SNAP10 (178.21 KB, text/x-log)
2014-03-26 06:17 EDT, IBM Bug Proxy
no flags Details
sosreport SNAP10 (3.85 MB, application/x-xz)
2014-03-26 06:17 EDT, IBM Bug Proxy
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 99398 None None None Never

  None (edit)
Description IBM Bug Proxy 2013-11-05 10:10:40 EST
== Comment: #0 - Shubham Goyal <shubgoya@in.ibm.com> - 2013-11-05 03:40:18 ==
Description of problem: It seems that strict password checking is not working while authenticating for vnc password after starting vnc server. I gave '123456789' as vnc password but could connect to vnc server using below passwords as well:

'12345678'
'1234567890'
'12345678901234'

I believe that a user should be able to connect to vnc server only if he provides a exact valid password which was provided earlier before starting vnc server.

How reproducible: Always

Version-Release number of selected component (if applicable):
3.11.0-300.fc20.ppc64p7  :  junoiocplus2-lp4 

Steps to Reproduce:

1) Trigger a new vnc installation & provide a password to authenticate connection to vnc server.
2) Try passwords (like mentioned above) which are deviating from original password.
3) You will be able to connect to vnc server.

Actual results: Able to connect to vnc server even with wrong passwords

Expected results: Installer should throw an error if user tries to connect with any password other than originally provided one.

Additional info: Let me know if you need any.
Comment 1 David Shea 2013-11-05 10:35:35 EST
I believe that the 8-character password is a limitation of the VNC protocol. Reassigning to tigervnc to confirm.
Comment 2 Tim Waugh 2013-11-08 06:12:37 EST
That's correct.
Comment 3 IBM Bug Proxy 2013-11-11 16:40:27 EST
------- Comment From hamzy@us.ibm.com 2013-11-11 21:34 EDT-------
Posted a potential patch to the ML:

https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-November/007114.html
Comment 4 Mark Hamzy 2013-11-13 15:43:50 EST
This can (and should) be fixed in anaconda.
Comment 5 Mark Hamzy 2013-11-13 15:47:03 EST
Posted another potential patch to the ML:

https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-November/007209.html
Comment 7 IBM Bug Proxy 2013-12-10 14:12:23 EST
------- Comment From hannsj_uhl@de.ibm.com 2013-12-10 19:07 EDT-------
*** Bug 100745 has been marked as a duplicate of this bug. ***
Comment 8 IBM Bug Proxy 2013-12-19 06:10:49 EST
------- Comment From shubgoya@in.ibm.com 2013-12-19 11:03 EDT-------
Am able to reproduce this bug in F20 PPC GA as well. Seems that the anaconda patch is not merged. Below is the ISO I used:

http://ppc.koji.fedoraproject.org/stage/f20-20131215-GA-RC1.0/Fedora/ppc64/iso/

Thanks...
Comment 10 IBM Bug Proxy 2014-01-22 17:20:35 EST
------- Comment From chavez@us.ibm.com 2014-01-22 22:17 EDT-------
Hello Red Hat,

Your bug states this is reportedly fixed in anaconda-19.31.42-1 which looks to be in snapshot 2. We received a similar report on s390x with snapshot 2 that states the following (below). Can you confirm the fix is there in snapshot 2 and whether the report from s390x testing is the same or a different problem please? We can mirror a new bug if you think it is a different problem. Thanks.

===================================
The issue is observed while installing RHEL 7  snap2 on zvm

Steps :
1. Start the installation
2. Provide all the parameters via parm file
3. Select vnc mode of installtaion
4  Provide the password as  vnc12345 or abcd1234
5. Try connecting to vnc session with password as  vnc12345 or abcd12345678

Actual  - Able to login to the vnc session .  The issue is not reproducible if the password length is less than 8 characters
Anaconda  do the substring match like if password is vnc12345  and user entered  vnc123456  than we are able to login
Comment 11 Vratislav Podzimek 2014-01-23 03:19:33 EST
(In reply to IBM Bug Proxy from comment #10)
> ------- Comment From chavez@us.ibm.com 2014-01-22 22:17 EDT-------
> Hello Red Hat,
> 
> Your bug states this is reportedly fixed in anaconda-19.31.42-1 which looks
> to be in snapshot 2. We received a similar report on s390x with snapshot 2
> that states the following (below). Can you confirm the fix is there in
> snapshot 2 and whether the report from s390x testing is the same or a
> different problem please? We can mirror a new bug if you think it is a
> different problem. Thanks.
> 
> ===================================
> The issue is observed while installing RHEL 7  snap2 on zvm
> 
> Steps :
> 1. Start the installation
> 2. Provide all the parameters via parm file
I suppose 'parm file' means kickstart file, right?

> 3. Select vnc mode of installtaion
> 4  Provide the password as  vnc12345 or abcd1234
> 5. Try connecting to vnc session with password as  vnc12345 or abcd12345678
> 
> Actual  - Able to login to the vnc session .  The issue is not reproducible
> if the password length is less than 8 characters
> Anaconda  do the substring match like if password is vnc12345  and user
> entered  vnc123456  than we are able to login
It's not Anaconda who does the substring matching, it's VNC who generally uses only first 8 characters from the password.

Anyway, this is a related but slightly different issue and it needs a patch in the pykickstart component, not the anaconda component. I'm gonna clone this bug and assign the cloned one to pykickstart.
Comment 12 Georg Markgraf 2014-01-28 08:01:22 EST
This problem also occur on System z. 

It should be intrinsic, but just to be save: 
Please ensure that this fix and the fix for pykickstart component (RHBZ 1056939) get integrated for System z as well.
Comment 13 IBM Bug Proxy 2014-02-13 04:54:11 EST
------- Comment From shubgoya@in.ibm.com 2014-02-13 09:42 EDT-------
I tested the fix on RHEL7Snap6 (Kernel 3.10.0-84.el7.ppc64) & I think this issue is partially fixed. I gave '12345678' as vnc password. Below are the cases which I tried to connect via vnc server:

'123456' - Not allowed to connect - This case is fixed

'1234567890' - Still able to connect - Issue still persists

So it seems that if the password tried (to connect vnc server) is a subset of the original password than proper checks are applied but if any additional characters are appended in the correct password than proper checking is not implemented. Ideally I should be able to connect only with the password I provided.

Thanks...
Comment 14 Vratislav Podzimek 2014-02-17 03:43:05 EST
(In reply to IBM Bug Proxy from comment #13)
> ------- Comment From shubgoya@in.ibm.com 2014-02-13 09:42 EDT-------
> I tested the fix on RHEL7Snap6 (Kernel 3.10.0-84.el7.ppc64) & I think this
> issue is partially fixed. I gave '12345678' as vnc password. Below are the
> cases which I tried to connect via vnc server:
> 
> '123456' - Not allowed to connect - This case is fixed
> 
> '1234567890' - Still able to connect - Issue still persists
> 
> So it seems that if the password tried (to connect vnc server) is a subset
> of the original password than proper checks are applied but if any
> additional characters are appended in the correct password than proper
> checking is not implemented. Ideally I should be able to connect only with
> the password I provided.
> 
> Thanks...
The incorrect behaviour described above is a limitation of the VNC protocol itself and cannot be fixed in the Anaconda installer.
Comment 15 IBM Bug Proxy 2014-02-17 08:23:31 EST
------- Comment From cdeadmin@us.ibm.com 2014-02-17 08:43 EDT-------
Comment 16 IBM Bug Proxy 2014-02-24 08:40:46 EST
------- Comment From iranna.ankad@in.ibm.com 2014-02-24 13:36 EDT-------
(In reply to comment #24)
> (In reply to IBM Bug Proxy from comment #13)
> > I tested the fix on RHEL7Snap6 (Kernel 3.10.0-84.el7.ppc64) & I think this
> > issue is partially fixed. I gave '12345678' as vnc password. Below are the
> > cases which I tried to connect via vnc server:
> >
> > '123456' - Not allowed to connect - This case is fixed
> >
> > '1234567890' - Still able to connect - Issue still persists
> >
> > So it seems that if the password tried (to connect vnc server) is a subset
> > of the original password than proper checks are applied but if any
> > additional characters are appended in the correct password than proper
> > checking is not implemented. Ideally I should be able to connect only with
> > the password I provided.
> >
> > Thanks...
> The incorrect behaviour described above is a limitation of the VNC protocol
> itself and cannot be fixed in the Anaconda installer.

1st case is important & good that it is fixed. I think 2nd case can be contained, its not of a concern.
So..we are OK to close this bug.

Thanks!
Comment 17 Peter Kotvan 2014-03-06 07:27:41 EST
Verified according to comment 16.
Comment 18 Martin Kolman 2014-03-26 06:12:48 EDT
*** Bug 1080641 has been marked as a duplicate of this bug. ***
Comment 19 IBM Bug Proxy 2014-03-26 06:17:26 EDT
Created attachment 878941 [details]
anaconda.log SNAP10

default comment by bridge
Comment 20 IBM Bug Proxy 2014-03-26 06:17:29 EDT
Created attachment 878942 [details]
anaconda.program.log SNAP10

default comment by bridge
Comment 21 IBM Bug Proxy 2014-03-26 06:17:32 EDT
Created attachment 878943 [details]
anaconda.ifcfg.log SNAP10

default comment by bridge
Comment 22 IBM Bug Proxy 2014-03-26 06:17:35 EDT
Created attachment 878944 [details]
anaconda.storage.log SNAP10

default comment by bridge
Comment 23 IBM Bug Proxy 2014-03-26 06:17:45 EDT
Created attachment 878945 [details]
sosreport SNAP10

default comment by bridge
Comment 24 IBM Bug Proxy 2014-05-06 09:42:01 EDT
------- Comment From chavez@us.ibm.com 2014-05-06 13:38 EDT-------
*** Bug 109963 has been marked as a duplicate of this bug. ***
Comment 25 Ludek Smid 2014-06-13 07:16:55 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

Note You need to log in before you can comment on or make changes to this bug.