Local privilege Escalation in SmartLine DeviceLock 5.73

Risk: Medium
Local: Yes
Remote: No
CWE: CWE-Other

CVSS Base Score: 4.9/10
Impact Subscore: 6.9/10
Exploitability Subscore: 3.9/10
Exploit range: Local
Attack complexity: Low
Authentication: No required
Confidentiality impact: Complete
Integrity impact: None
Availability impact: None

The vulnerability constitutes of wrong ACLs on Device Object permission set by the driver. Whenever your ACLs on a harddrive or partition, as configured by DeviceLock Manager, only consists of Allow entries (and Deny being the default), then the driver sets the ACLs on the kernel's internal object \Device\HarddiskX\PartitionY to Everyone:FullAccess, which allows complete read and write access to the raw file system, circumventing all access restrictions of NTFS. This behaviour can be easily verified by using Sysinternals' WinObj and dd.exe (dd if=\\.\C: | grep 'somesecretstuff') from GunWin32 or Win32-BinUtils (Cygwin should do the job as well) with a restricted user account. In contrast, at least one explicit Deny entry leads to applying Everyone:DenyFullAccess, which effectively locks out even administrator users and the system, leading to certain problems with the Logical Volume Manager and some other system management utilities. The vendor SmartLine has been informed about this vulnerability some weeks ago and verified it. However, they don't intend to release any patch, but rather refered to the upcoming version 6 of their software. Workaround: I didn't bother to check other objects for misplaced ACLs as well, but creating at least one explicit deny entry (as discussed above) should at least fix the vulnerability. It might also be possible to write a program that readjusts the ACLs on every reboot. Better uninstall this software at once.

Vote for this issue:


Thanks for you vote!


Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.

(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2022, cxsecurity.com


Back to Top