View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001159 | Main CAcert Website | source code | public | 2013-03-20 20:27 | 2013-11-03 21:26 |
Reporter | mutax | Assigned To | BenBE | ||
Priority | immediate | Severity | major | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Platform | Main CAcert Website | OS | N/A | OS Version | stable |
Product Version | 2013 Q1 | ||||
Target Version | 2013 Q2 | Fixed in Version | 2013 Q2 | ||
Summary | 0001159: it might be possible to execute commands on the signing server | ||||
Description | in server.pl there is this code: if($fields[1]) { open OUT,">timesync.sh"; print OUT "date -u $fields[1]\n"; print OUT "hwclock --systohc\n"; close OUT; } as hwclock is beeing called the resulting snippet in the file OUT will be run as root. Given this when adding arbitrary commands like '| rm -Rf /*' in $fields[1] they will be executed. when looking at client.pl: my $timestamp=strftime("%m%d%H%M%Y.%S",gmtime); Request($ver,0,0,0,0,0,0,0,$timestamp,"",""); an attacker with access to the frontend machine could issue Request($ver,0,0,0,0,0,0,0,'| rm -Rf /* ',"",""); to execute this command as root. | ||||
Tags | No tags attached. | ||||
Reviewed by | NEOatNHNG, BenBE | ||||
Test Instructions | |||||
|
An attacker with root access to the frontend machine, i.e. the CAcert webdb server, can do too many bad things to mention obviously. But I guess that the point that this reporter wants to make is that he could also wipe out the signing server. That would indeed be even worse. Fortunately, I can tell you that the timesync.sh snippet created by server.pl is *NEVER* executed automatically. Only when CAcert's critical system administrators are visiting the secured data centre and actually logging into the signing server for maintenance, they may use the script for manually synchronizing time between the signing server and the webdb server. Before running the script, its content will always be visually inspected and compared with the actual time of day. Nevertheless I am grateful for the report -- it is important to realize this weakness in case someone would want to fully automate the time synchronization between signer and webserver. Clearly, more controls would need to be in place then. |
|
The attacker does not neccessarily need root access to the frontend machine, only access to either the serial port or the script that creates the signing requests. Also your note sounds not very convincing to me - manual inspection is not sufficient here, you want to control exactly and validate any data accepted at the signing server. I suggest at least to add a regex to only accept valid timestamps. Also: Maybe another solution like a gps time receiver would be better suitable and allow tighter time synchronisation than a manually executed command, but thats another topic. |
|
I have implemented a fix and put it on the test server. Please review and do some regression testing (if signing still works etc) |
|
I just created a server certificate =>ok |
|
Patch looks okay and sane to me. |
|
I just created a client certificate => ok |
|
i create a client cert => works |
|
As at least 3 test are available please deploy |
|
The patch has been installed on the production server on June 19, 2013, during a visit to the hosting facility. The signer process has been restarted after installing the fix. On June 20, the patch has also been installed on the webdb server, so it is recorded in the CVS revision control system. See also: https://lists.cacert.org/wws/arc/cacert-systemlog/2013-06/msg00008.html |
Date Modified | Username | Field | Change |
---|---|---|---|
2013-03-20 20:27 | mutax | New Issue | |
2013-03-21 10:14 | wytze | Note Added: 0003840 | |
2013-03-21 11:05 | mutax | Note Added: 0003841 | |
2013-03-21 11:17 | mutax | Note View State: 0003841: private | |
2013-03-21 11:18 | mutax | Note View State: 0003841: public | |
2013-04-09 22:00 | NEOatNHNG | Source_changeset_attached | => cacert-devel testserver-stable 2edf1f6d |
2013-04-09 22:00 | NEOatNHNG | Source_changeset_attached | => cacert-devel testserver-stable a3d0b8aa |
2013-04-09 22:23 | NEOatNHNG | Reviewed by | => NEOatNHNG |
2013-04-09 22:23 | NEOatNHNG | Note Added: 0003870 | |
2013-04-09 22:23 | NEOatNHNG | Status | new => needs review & testing |
2013-04-09 22:50 | INOPIAE | Note Added: 0003871 | |
2013-04-09 22:50 | INOPIAE | Note Edited: 0003871 | |
2013-04-10 16:38 | BenBE | Reviewed by | NEOatNHNG => NEOatNHNG, BenBE |
2013-04-10 16:38 | BenBE | Note Added: 0003873 | |
2013-04-10 16:38 | BenBE | Assigned To | => BenBE |
2013-04-10 16:38 | BenBE | Status | needs review & testing => needs testing |
2013-04-10 16:38 | BenBE | Product Version | => 2013 Q1 |
2013-04-10 16:38 | BenBE | Target Version | => 2013 Q2 |
2013-04-14 09:54 | Werner Dworak | Note Added: 0003883 | |
2013-04-16 20:09 | MartinGummi | Note Added: 0003887 | |
2013-04-16 20:52 | INOPIAE | Note Added: 0003890 | |
2013-04-16 20:52 | INOPIAE | Status | needs testing => ready to deploy |
2013-05-13 16:50 | BenBE | Source_changeset_attached | => cacert-devel release adec6700 |
2013-06-20 10:20 | wytze | Note Added: 0004074 | |
2013-06-20 10:20 | wytze | Status | ready to deploy => solved? |
2013-06-20 10:20 | wytze | Fixed in Version | => 2013 Q2 |
2013-06-20 10:20 | wytze | Resolution | open => fixed |
2013-08-03 08:36 | BenBE | View Status | private => public |
2013-11-03 21:26 | INOPIAE | Status | solved? => closed |