IPA/FreeIPA server can store SSH public keys so that they can be managed centrally. It was found that that when an account was disabled, either due to policy (too many login failures) or by an administrator locking the account, the user was still able to log into the system if their SSH public key was stored in the IPA datastore. This could allow for unauthorized access in very specific scenarios (a user account must exist and be locked, and an SSH public key must be stored in IPA and in the possession of the remote user).
Acknowledgements: This issue was discovered by Rob Crittenden of Red Hat.
I did some investigation and this is what I have found out: 1. If local user is locked using "passwd -l", sshd allows login. In other words, locked users can log in using SSH public keys even without IPA. 2. If IPA user is locked using "ipa user-disable", sshd does not allow login. 3. If IPA user is locked as a result of too many unsuccessful kinits, sshd allows login. I think that Kerberos principal lockout must be checked in pam_sss during PAM account phase in order to fix this.
I can confirm Honza's finding. If the user authenticated with his Kerberos credentials, then the authentication fails (as it should) in the krb5_child: ----- (Fri Jun 14 15:16:02 2013) [[sssd[krb5_child[1244]]]] [get_and_save_tgt] (0x0020): 1108: [-1765328366][Clients credentials have been revoked] (Fri Jun 14 15:16:02 2013) [[sssd[krb5_child[1244]]]] [map_krb5_error] (0x0020): 1159: [-1765328366][Clients credentials have been revoked] ----- (Also, there is a subtle but unrelated error where we fail to map the Kerberos error into a meaningful PAM error code and just report System Error) But when authentication is handled by other means, such as SSH public keys, only the access handler of IPA provider is consulted. The access handler currently only checks the nsaccountlock attribute as Honza noted in point 2. above. Setting access_provider=krb5 doesn't help here, because that only calls krb5_kuserok() which only checks if the principal can log in as a user at all. From client perspective it would be best if the lockout information was propagated from the client side to come central attribute, perhaps even the account lock. Rob/Simo, what do you think?
We'd probably need to define some new schema in order to define an attribute like lockoutExpirationDate which defines when a lockout expires. If the date doesn't exist at all, or the current time (GMT) is greater than the lockoutExpirationDate then the user is granted access. This is just off the top of my head though. Right now this is calculated on-the-fly by the KDC and the 389-ds lockout plugin. This would also mean that changes to password policy would not be immediately reflected in users that are currently locked out.
(In reply to Jakub Hrozek from comment #3) > From client perspective it would be best if the lockout information was > propagated from the client side to come central attribute, perhaps even the ^^^^^^ I meant "propagated from the server side here but I guess Rob was able to translate my mistake :)
(In reply to Rob Crittenden from comment #4) > We'd probably need to define some new schema in order to define an attribute > like lockoutExpirationDate which defines when a lockout expires. If the date > doesn't exist at all, or the current time (GMT) is greater than the > lockoutExpirationDate then the user is granted access. This is just off the > top of my head though. > > Right now this is calculated on-the-fly by the KDC and the 389-ds lockout > plugin. > > This would also mean that changes to password policy would not be > immediately reflected in users that are currently locked out. OK, this sounds great, but also sounds like a forward-looking effort to me. Do you know what the client should check with the current schema either with the KDC or in LDAP to detect the KDC lockout short of actually performing the kinit? I checked the user attributes but only realized I've been out of server development for too long and don't remember the details.
(In reply to Jakub Hrozek from comment #3) > Setting access_provider=krb5 doesn't help here, because that only calls > krb5_kuserok() which only checks if the principal can log in as a user at > all. IMO it would be best to do all the additional checks using pure krb5 calls as well, but judging from your comments I guess that is not possible, is that correct? (In reply to Jakub Hrozek from comment #6) > Do you know what the client should check with the current schema either with > the KDC or in LDAP to detect the KDC lockout short of actually performing > the kinit? I checked the user attributes but only realized I've been out of > server development for too long and don't remember the details. You can find all the details in the ipa-lockout DS plugin source.
(In reply to Jan Cholasta from comment #7) > (In reply to Jakub Hrozek from comment #3) > > Setting access_provider=krb5 doesn't help here, because that only calls > > krb5_kuserok() which only checks if the principal can log in as a user at > > all. > > IMO it would be best to do all the additional checks using pure krb5 calls > as well, but judging from your comments I guess that is not possible, is > that correct? > Is there any way to just ask the IPA server if an account is locked just based on the knowledge of principal? I'm not aware of any way just from the account phase. Even according to http://web.mit.edu/kerberos/krb5-devel/doc/admin/lockout.html you need to authtok and attempt to get a ticket. > (In reply to Jakub Hrozek from comment #6) > > Do you know what the client should check with the current schema either with > > the KDC or in LDAP to detect the KDC lockout short of actually performing > > the kinit? I checked the user attributes but only realized I've been out of > > server development for too long and don't remember the details. > > You can find all the details in the ipa-lockout DS plugin source. If authentication is performed by other means, like SSH key, there is no bind and the lockout plugin is not called. Also, from the client, the attributes like krbPwdMaxFailure are not readable with host keytab.
(In reply to Jakub Hrozek from comment #8) > (In reply to Jan Cholasta from comment #7) > > (In reply to Jakub Hrozek from comment #3) > > > Setting access_provider=krb5 doesn't help here, because that only calls > > > krb5_kuserok() which only checks if the principal can log in as a user at > > > all. > > > > IMO it would be best to do all the additional checks using pure krb5 calls > > as well, but judging from your comments I guess that is not possible, is > > that correct? > > > > Is there any way to just ask the IPA server if an account is locked just > based on the knowledge of principal? I'm not aware of any way just from the > account phase. Even according to > http://web.mit.edu/kerberos/krb5-devel/doc/admin/lockout.html you need to > authtok and attempt to get a ticket. It seems that the lockout information of a principal is available from kadmin, can we take advantage of this somehow? Perhaps give limited kadmin access to hosts? > > > (In reply to Jakub Hrozek from comment #6) > > > Do you know what the client should check with the current schema either with > > > the KDC or in LDAP to detect the KDC lockout short of actually performing > > > the kinit? I checked the user attributes but only realized I've been out of > > > server development for too long and don't remember the details. > > > > You can find all the details in the ipa-lockout DS plugin source. > > If authentication is performed by other means, like SSH key, there is no > bind and the lockout plugin is not called. Also, from the client, the > attributes like krbPwdMaxFailure are not readable with host keytab. Sure, I was merely pointing you to code that implements lockout logic.
(In reply to Jakub Hrozek from comment #8) > Is there any way to just ask the IPA server if an account is locked just > based on the knowledge of principal? I'm not aware of any way just from the > account phase. Even according to > http://web.mit.edu/kerberos/krb5-devel/doc/admin/lockout.html you need to > authtok and attempt to get a ticket. Not to my knowledge, at least not without binding somehow. > If authentication is performed by other means, like SSH key, there is no > bind and the lockout plugin is not called. Also, from the client, the > attributes like krbPwdMaxFailure are not readable with host keytab. Exactly. And providing this over an unauthenticated channel would be bad.
(In reply to Rob Crittenden from comment #10) > (In reply to Jakub Hrozek from comment #8) > > Is there any way to just ask the IPA server if an account is locked just > > based on the knowledge of principal? I'm not aware of any way just from the > > account phase. Even according to > > http://web.mit.edu/kerberos/krb5-devel/doc/admin/lockout.html you need to > > authtok and attempt to get a ticket. > > Not to my knowledge, at least not without binding somehow. > > > If authentication is performed by other means, like SSH key, there is no > > bind and the lockout plugin is not called. Also, from the client, the > > attributes like krbPwdMaxFailure are not readable with host keytab. > > Exactly. And providing this over an unauthenticated channel would be bad. Is there any such info that can be retrieved using host credentials? If not, can we create one? Maybe during the first kinit/bind that goes above the threshold, set the nsAccountLock attribute? Otherwise I'm not sure what a client could do..
(In reply to Jakub Hrozek from comment #11) > (In reply to Rob Crittenden from comment #10) > > (In reply to Jakub Hrozek from comment #8) > > > Is there any way to just ask the IPA server if an account is locked just > > > based on the knowledge of principal? I'm not aware of any way just from the > > > account phase. Even according to > > > http://web.mit.edu/kerberos/krb5-devel/doc/admin/lockout.html you need to > > > authtok and attempt to get a ticket. > > > > Not to my knowledge, at least not without binding somehow. > > > > > If authentication is performed by other means, like SSH key, there is no > > > bind and the lockout plugin is not called. Also, from the client, the > > > attributes like krbPwdMaxFailure are not readable with host keytab. > > > > Exactly. And providing this over an unauthenticated channel would be bad. > > Is there any such info that can be retrieved using host credentials? > > If not, can we create one? Maybe during the first kinit/bind that goes above > the threshold, set the nsAccountLock attribute? > > Otherwise I'm not sure what a client could do.. We might set the nsAccountLock attribute on kerbero auto-lockouts, but then we would not be able to autounlock, which is what we do after some time passed. I think the only way to solve this properly is to add an extended operation by which an authenticated user can ask about lock status of other users. The probelm is also to find out when to check this. We do not want to unconditioanlly perform this check even when regular authentication is used as it would just be yet another roundtrip to the server which we do not need as auth would have already returned all fine. But maybe we can optimize this by caching in sssd for a few seconds so that this code is only called when the pam account stack is called w/o the auth stack being called first. All that said I wonder if we need to care at all about kerberos lockouts ? These are ephemeral, meaning they are not permanent, if the user is using a valid ssh key to log in I do not think we have any business in preventing access. I think we could simply check exclusively nsAccountLock for *intentional* admin disabled users, and ignore kerberos auto-lockouts here. Checking nsAccountLock should be simple and will require no extension at all.
(In reply to Simo Sorce from comment #12) > I think we could simply check exclusively nsAccountLock for > *intentional* admin disabled users, and ignore kerberos auto-lockouts here. > > Checking nsAccountLock should be simple and will require no extension at all. We already do check nsAccountLock during access phase and as Honza noted (and I confirmed during my testing), that's working fine.
(In reply to Jakub Hrozek from comment #13) > We already do check nsAccountLock during access phase and as Honza noted > (and I confirmed during my testing), that's working fine. ssh access actually works for me though, in F-18 anyway: $ rpm -q sssd freeipa-server sssd-1.9.4-8.fc18.x86_64 freeipa-server-3.1.4-1.fc18.x86_64 ipaserver $ ipa user-show rcrit User login: rcrit First name: Rob Last name: Crittenden Home directory: /home/rcrit Login shell: /bin/sh Email address: rcrit UID: 1968800001 GID: 1968800001 Account disabled: True Password: True Member of groups: ipausers Kerberos keys available: True SSH public key fingerprint: 92:13:47:D6:E7:F1:AA:C4:B0:73:BF:C2:9C:32:CC:3E rcrit.com (ssh-rsa) client $ slogin rcrit@ipaserver ...snip... debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/rcrit/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 279 debug1: read PEM private key done: type RSA debug1: Authentication succeeded (publickey). ...snip... Last login: Mon Jun 17 11:02:40 2013 from client.example.com ipaserver $ Some locked accounts don't allow unlocking, should that make a difference? If not then I agree with Simo, use nsaccountlock only.
(In reply to Simo Sorce from comment #12) > (In reply to Jakub Hrozek from comment #11) > > (In reply to Rob Crittenden from comment #10) > > > (In reply to Jakub Hrozek from comment #8) > > > > Is there any way to just ask the IPA server if an account is locked just > > > > based on the knowledge of principal? I'm not aware of any way just from the > > > > account phase. Even according to > > > > http://web.mit.edu/kerberos/krb5-devel/doc/admin/lockout.html you need to > > > > authtok and attempt to get a ticket. > > > > > > Not to my knowledge, at least not without binding somehow. > > > > > > > If authentication is performed by other means, like SSH key, there is no > > > > bind and the lockout plugin is not called. Also, from the client, the > > > > attributes like krbPwdMaxFailure are not readable with host keytab. > > > > > > Exactly. And providing this over an unauthenticated channel would be bad. > > > > Is there any such info that can be retrieved using host credentials? > > > > If not, can we create one? Maybe during the first kinit/bind that goes above > > the threshold, set the nsAccountLock attribute? > > > > Otherwise I'm not sure what a client could do.. > > We might set the nsAccountLock attribute on kerbero auto-lockouts, but then > we would not be able to autounlock, which is what we do after some time > passed. > True, I didn't realize there is autounlock and thought that only admin can unlock the account (which would reset the nsAccountLock) > I think the only way to solve this properly is to add an extended operation > by which an authenticated user can ask about lock status of other users. > > The probelm is also to find out when to check this. We do not want to > unconditioanlly perform this check even when regular authentication is used > as it would just be yet another roundtrip to the server which we do not need > as auth would have already returned all fine. > > But maybe we can optimize this by caching in sssd for a few seconds so that > this code is only called when the pam account stack is called w/o the auth > stack being called first. > Yes, this sounds like a good approach, because if auth ran, the lockout would have kicked the user out during auth phase. It's also pretty much in agreement with what Rob suggested in comment #4. > All that said I wonder if we need to care at all about kerberos lockouts ? In general I agree, I'd just like to make sure we have a plan. > These are ephemeral, meaning they are not permanent, if the user is using a > valid ssh key to log in I do not think we have any business in preventing > access. I think we could simply check exclusively nsAccountLock for > *intentional* admin disabled users, and ignore kerberos auto-lockouts here. > > Checking nsAccountLock should be simple and will require no extension at all.
Ok, let's sum the case. I tend to agree with Simo that people being able to log in with SSH keys when the account is temporarily locked down because of too many password guesses is not a bug. But I think this is also something where we would want Vincent's agreement. So if I read the Bug right, the only left issue is that client can still log in when account is administratively locked (Comment 14). This would imply SSSD fix? I also do not understand the discrepancy between Jakub's statement in Comment 13 and Rob's test in Comment 14. If the nsAccoungLock is enforced, why Rob logged in?
I don't know yet, I need to carefully re-test again. Rob, was pam_sss mentioned in /var/log/secure for the account phase? (it should) Is access_provider set to ipa in your case?
This is all there is: Jun 18 09:41:21 ipaserver sshd[4666]: pam_unix(sshd:session): session closed for user rcrit Jun 18 09:41:24 ipaserver sshd[4750]: Accepted publickey for rcrit from 192.168.196.13 port 48479 ssh2 Jun 18 09:41:24 ipaserver sshd[4750]: pam_unix(sshd:session): session opened for user rcrit by (uid=0) Yes, access_provider is ipa. I'm logging in from an IPA-enrolled client into the IPA server itself.
(In reply to Martin Kosek from comment #16) > Ok, let's sum the case. I tend to agree with Simo that people being able to > log in with SSH keys when the account is temporarily locked down because of > too many password guesses is not a bug. But I think this is also something > where we would want Vincent's agreement. > > So if I read the Bug right, the only left issue is that client can still log > in when account is administratively locked (Comment 14). This would imply > SSSD fix? I also do not understand the discrepancy between Jakub's statement > in Comment 13 and Rob's test in Comment 14. If the nsAccoungLock is > enforced, why Rob logged in? I'm not 100% sure. I'll have to solicit some other opinions from SRT, but it seems to me that if an account is locked out that it should require some form of administrator reset. I know that password != ssh key, but if the policy is to lock the account, then the _account_ should be locked. But if that's not a universal principal (i.e. if an account is locked due to ssh password failures, can they still log in locally? If the answer to that is yes, then probably we should continue to allow ssh key-based logins).
Jakub, what is your opinion on Comment 19? Do you have test results you planned to do in Comment 17? We need to soon define scope of implementation and start implementing the fix.
This came up somewhat in an internal IRC chat this morning. A customer was trying something similar with winbind. asn opened this samba bug https://bugzilla.samba.org/show_bug.cgi?id=9928 The support engineer (nc) wondered how sssd would handle it, and discovered the same thing we did. I've asked him to keep this to himself. The customer is not aware that this also happens in sssd. For the purposes of deciding if this makes it public, here is the conversation (TZ is EST): [08:17] nc Hi ipa, when we use sssd-ad it uses ldap_account_expire_policy=ad right? (ie; checks userAccessControl attribute?) [08:20] ab nc: yes [08:21] nc ab: I'm trying to login using a disabled user and ssh keys.. sshd calls PAM_ACCT_MGMT and sssd returns success.. i think it should fail as the user account is disabled. [08:22] nc userAccountControl: 514 [08:22] nc ^^ it's from the user entry [08:22] ab nc: enable debug and see whether this value is cached in sysdb [08:24] nc ab: yes, it is stored http://pastebin.test.redhat.com/150865 [08:24] nc it shows .. adUserAccountControl: 514 [08:26] ab nc: with debug level 9 you can see "Perfoming AD access check for user ..." [08:26] ab "User account control for user [..] is [..]" [08:35] nc ab: nope.. I dont see messages similar to above [08:35] ab what version is that? [08:35] nc ab: sssd-1.9.2-82.7.el6_4.x86_64 [08:37] ab the message should be there, sdap_account_expired_ad() in 1.9.2 is no different from git master in this context
(In reply to Rob Crittenden from comment #14) > $ rpm -q sssd freeipa-server > sssd-1.9.4-8.fc18.x86_64 > freeipa-server-3.1.4-1.fc18.x86_64 > > ipaserver $ ipa user-show rcrit > User login: rcrit > First name: Rob > Last name: Crittenden > Home directory: /home/rcrit > Login shell: /bin/sh > Email address: rcrit > UID: 1968800001 > GID: 1968800001 > Account disabled: True > Password: True > Member of groups: ipausers > Kerberos keys available: True > SSH public key fingerprint: 92:13:47:D6:E7:F1:AA:C4:B0:73:BF:C2:9C:32:CC:3E > rcrit.com (ssh-rsa) > > client $ slogin rcrit@ipaserver > ...snip... > debug1: Next authentication method: publickey > debug1: Offering RSA public key: /home/rcrit/.ssh/id_rsa > debug1: Server accepts key: pkalg ssh-rsa blen 279 > debug1: read PEM private key done: type RSA > debug1: Authentication succeeded (publickey). > ...snip... > Last login: Mon Jun 17 11:02:40 2013 from client.example.com > ipaserver $ > > Some locked accounts don't allow unlocking, should that make a difference? > If not then I agree with Simo, use nsaccountlock only. I tried to reproduce this bug, but I was unable to connect to another machines with publickey. [root@vm-077 ~]# rpm -q sssd freeipa-server sssd-1.9.4-8.fc18.x86_64 freeipa-server-3.1.4-1.fc18.x86_64 [root@vm-077 ~]# ipa user-show sshuser01 User login: sshuser01 First name: sshuser01 Last name: sshuser01 Home directory: /opt/home/sshuser01 Login shell: /bin/sh Email address: sshuser01.eng.brq.redhat.com UID: 325600115 GID: 325600115 Account disabled: True Password: True Member of groups: ipausers Kerberos keys available: True SSH public key fingerprint: B9:9E:26:21:F2:DF:C7:88:36:37:97:87:F9:B4:C9:85 sshuser01.lab.bos.redhat.com (ssh-rsa) [sshuser01@vm-076] $ slogin -v sshuser01@vm-077 OpenSSH_6.1p1, OpenSSL 1.0.1c-fips 10 May 2012 ... snip ... debug1: Next authentication method: publickey debug1: Offering RSA public key: /opt/home/sshuser01/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 279 debug1: read PEM private key done: type RSA Connection closed by UNKNOWN
I was out of the office for 2 weeks, I see there was no response for a week. Jakub, what do you think about Comment 21 and Comment 22? Is this an SSSD issue? I am also confused with Comment 22, I thought that this is being reproduced all the time.
(In reply to Martin Kosek from comment #23) > I was out of the office for 2 weeks, I see there was no response for a week. > Jakub, what do you think about Comment 21 and Comment 22? Is this an SSSD > issue? > Logging in with locked account yields expected results for both me and Lukas. Administratively locked accounts are kicked out as they should. > I am also confused with Comment 22, I thought that this is being reproduced > all the time. Rob was seeing that he could log in with locked account. I couldn't reproduce the behaviour and I don't see how that could have happened. Since we can't reproduce what Rob is seeing, can we get access to the affected machines?
(In reply to Jakub Hrozek from comment #24) > (In reply to Martin Kosek from comment #23) > > I was out of the office for 2 weeks, I see there was no response for a week. > > Jakub, what do you think about Comment 21 and Comment 22? Is this an SSSD > > issue? > > > > Logging in with locked account yields expected results for both me and > Lukas. Administratively locked accounts are kicked out as they should. Ok. So IIUC, the problem currently only lies with logging with key to an account locked due to too many password failures (related - Comment 19). > > > I am also confused with Comment 22, I thought that this is being reproduced > > all the time. > > Rob was seeing that he could log in with locked account. I couldn't > reproduce the behaviour and I don't see how that could have happened. Since > we can't reproduce what Rob is seeing, can we get access to the affected > machines? Adding needsinfo? to Rob.
I figured out what I was seeing. I had an IPA user mirroring a local account for myself. Using that I can ssh in even if the IPA account is disabled. This is probably expected. If I ssh in with an IPA-only disabled user then that fails as expected.
Thanks for info. OK, is there any problem to solve after all? Since administrative lock properly prevents user in logging in via SSH keys, the only remaining issue seems to be that users can still use SSH keys to log when account is under temporary lock down due to too many password failures. Judging from Comment 19 and others I did not see a clear consensus if it is something we want/need to fix or not.
The real question here I guess is whether or not this happens with a regular local account. If you have a mechanism to lock a local account due to too many password failures (I can't think of one right now, but there's probably some pam module for this), would it permit password-less logins on a locked account? I think if we mimic existing behaviour for local accounts then we're ok. Also, if someone logs in with an ssh key on this temporarily locked account, what happens? Is the lock removed? Or they given a warning that someone was attempting to (possibly) brute-force the account? I have no strong feelings either way -- I mean, if there is an ssh key involved, chances are pretty good it's the legitimate user. But there should be some feedback to them regarding the account being locked and why. Does that happen? Note that I'm not necessarily saying that adding that kind of feature is a "fix" for a "security issue". Unless someone sees this as really bad behaviour, I think it's reasonable to turn that kind of feedback (if missing, dunno) into an RFE and discard these CVE names as being prematurely assigned. Thoughts? The biggest problem to me was the "administratively locked but still allowing ssh" report and it seems like that doesn't actually happen, so on my end, pending the above, I think we're good.
Ping? Can someone answer the questions I noted above? Basically I'd like to know whether or not this is a security flaw or not, but I can't say because I don't know the behaviour (so someone who does know, please speak up). I also suspect that bug #973428 is tied closely to this, so if we deem that _this_ bug is not a security flaw, then is it true that bug #973428 is not a security flaw either (considering how closely linked they are)? I think the big question here is in regards to the PAM bits. Can you ssh into a locked account with the ssh key or not? Seems that pam_tally2 can lock accounts on failed password attempts. I'll take a peek at pam_tally2 because it doesn't change /etc/passwd in terms of locking the account; pam_tally2 seems to deny based on it's own log (since it can do temporary or permanent locks, which is configurable). I don't know if that impacts ssh keys though.
Ok, I looked at pam_tally2. If try to authenticate with a wrong password, the tally count increases and after the defined failures, despite giving the right password I cannot login. If I try to login with an ssh key, I can login. If I kinit and try to login, I can login. So pam_tally2 only prevents password-based login attempts if there are enough failed attempts. So in my mind, the current behaviour very much mimics a non-IPA/local setup using pam_tally2. So I would not consider this a security flaw. As an aside, pam_tally2 doesn't tell me the account is locked; I just keep getting password prompts (I was up to 22 failures before I realized it was working). The real question is about the expired accounts. Bug #973428 is regarding an expired account and I would expect that an expired account should not be allowed to login at all, regardless of how they try to login. But for this bug, I think it's not a security issue. Any disagreement?
I think your analysis pretty much aligns with what we've said above, so I agree completely. The only problem I can see is that accounts that are temporarily locked due to too many password failures are still able to log in using password ssh keys. There is a possible solution outlined in comment #12.
Citrix, the original reporter, is asking for status on this. I agree with the analysis that this isn't a security issue, Simo's point about password failures lockout vs account expiration in particular. It seems to me this is a call to add support for krbprincipalexpiration in IPA and sssd. What can I tell them?
Sorry, Rob, for the seriously long delay here. This got tucked away in a very large folder of bugspam I am just now weeding through. As this isn't a security flaw, I can't really comment on when it would get fixed. What I think would be ideal to see is it get fixed with the other issue (which I am still not sure we are treating as a security issue or not). That other issue is bug #973428. Since both issues are quite similar, it makes sense to fix them together even if one is security-relevant and the other is not. In the meantime I'm going to remove the CVE from this bug. I'm going to leave this bug as is, although if you want it assigned to something else, I can do that as well. My thoughts were to close this as NOTABUG because it's not a security issue, and keep it private so that the CVE name and such don't leak accidentally and cause more grief. Let me know if there is any disagreement to that.
I'm ok with this. I don't believe this is a CVE.
Ok, thanks for the confirmation. Closing this as NOTABUG. If you require this for any bugfix purpose, feel free to clone it.