Improper Authorization in veyon/veyon
Mar 2nd 2022
When veyon is used in a Linux environment and is configured to use PAM as authentication method, The authorization of an account validity is missing. Therefore expired accounts or accounts with expired passwords can still login.
This bug is in the provided tool
veyon-auth-helper - after an successful call to
pam_authenticate() it has been skipped to call
pam_acct_mgmt() which checks for authorization after authentication has been prooved.
Proof of Concept
First, Install veyon on linux and configure it to use PAM authentication method and create a user testuser
passwd testuser #12345
Then set the user to expire:
chage -E0 testuser
You now can still login with the testuser.
Since disabling an account still would allow login via ssh-keys or alike, it is common usage to expire an PAM account. This bug allows accounts that have been marked expired, and therefore should explicitly been denied access, to still login into veyon. I'm in no position to say how severe this is, I think the maintainer knows better how important this could be. Further I assume that PAM is not used much, but LDAP is used instead which could lower the total severity. That said I'm open for corrections on the score, but I think the worst case should be applied (after applying common sense).
Somehow it seems that my fix is not seen here. You can find it in github.com/ysf/veyon in the fix-pam branch.
Thank you very much! I just cherry picked it manually.
Thank you Tobias! @admin how can the fix be put on my stats?
@ysf - once the maintainer has confirmed the fix, they will be asked to select who fixed the vulnerability. Once this has been done by the maintainer, the fix will be made visible against your profile.
I think the severity is rather low, since usually access control is configured such that authenticated users additionally have to be part of a certain user group etc. so only teachers whose account is expired (and usually won't be able to login to the system and start Veyon Master anyway) would be able to access Veyon Clients. Therefore, we will not release a new version before next week. I guess we should wait with confirming a fix until then?
@Tobias, you are welcome to adjust the severity yourself to a lower score.
If you want the report to remain private until you have released an update, I would recommend only confirming the fix when this has been done, as confirming the fix makes the report public.
@Tobias as I wrote I couldn't estimate how severe this is, feel free to adjust as you like.
@Jamie I'd think it'll be a great feature to be able to fix an issue but - release it to the public after a new software has been released, not when it was fixed. Like it's in the original CVE Process.
@ysf - I would love to invite you to create a feature request on our public repository. This will allow us to better keep track of your request and keep you updated on any progress.
The fix is included in Veyon 4.7.3 - thank you for your research and contribution.