View Issue Details

IDProjectCategoryView StatusLast Update
0001159Main CAcert Websitesource codepublic2013-11-03 21:26
Reportermutax Assigned ToBenBE  
PriorityimmediateSeveritymajorReproducibilityhave not tried
Status closedResolutionfixed 
PlatformMain CAcert WebsiteOSN/AOS Versionstable
Product Version2013 Q1 
Target Version2013 Q2Fixed in Version2013 Q2 
Summary0001159: it might be possible to execute commands on the signing server
Descriptionin 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.

TagsNo tags attached.
Reviewed byNEOatNHNG, BenBE
Test Instructions

Activities

wytze

2013-03-21 10:14

developer   ~0003840

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.

mutax

2013-03-21 11:05

reporter   ~0003841

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.

NEOatNHNG

2013-04-09 22:23

administrator   ~0003870

I have implemented a fix and put it on the test server. Please review and do some regression testing (if signing still works etc)

INOPIAE

2013-04-09 22:50

updater   ~0003871

Last edited: 2013-04-09 22:50

I just created a server certificate
=>ok

BenBE

2013-04-10 16:38

updater   ~0003873

Patch looks okay and sane to me.

Werner Dworak

2013-04-14 09:54

updater   ~0003883

I just created a client certificate => ok

MartinGummi

2013-04-16 20:09

updater   ~0003887

i create a client cert => works

INOPIAE

2013-04-16 20:52

updater   ~0003890

As at least 3 test are available please deploy

wytze

2013-06-20 10:20

developer   ~0004074

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

Issue History

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