Project

General

Profile

Actions

Feature #58819

closed

check the core for modifications

Added by Bernd Wilke over 10 years ago. Updated over 4 years ago.

Status:
Rejected
Priority:
Could have
Assignee:
-
Category:
Install Tool
Target version:
-
Start date:
2014-05-15
Due date:
% Done:

0%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:
Needs Decision

Description

if an earlier admin changed the core there is no hint about it.
also if an installation has been corrupted (invalid unzip, malice modification, ...) there is no notice or quick test for it.

A new check in the installtool for an unmodified core would be nice:

'the core files are unmodified'

'the following core files have been changed:
- typo3/index.php
- ...'

Actions #1

Updated by Markus Klein over 10 years ago

The also needs to be a tool for generating this hash information.

This tools is necessary for:
  1. Release creation
  2. Developers which need to modify things and want to "sign" the state
Actions #2

Updated by Bernd Wilke over 10 years ago

@Markus:
IMHO your second point is dangerous as it hides any changes:
every following check of the checksums would return 'no changes done' which is correct and not correct.

correct: no changes after the last checksum calculation,

but as it does not change the original source (at typo3.org) it also is

not correct: there are changes compared to the original files (from typo3.org)

and it is obvious that a tool is neccessary which generates the checksums for a new release so the checksums can be compared lateron

Actions #3

Updated by Markus Klein over 10 years ago

I guess we need two checksums then. One that signs the original Core and one that can be used by agencies to sign their modifications.

It's not so obvious these tools are there. For instance AFAIK there's never been an official tool to create the md5 checksums for the former emconf checksums.

Actions #4

Updated by Susanne Moog over 9 years ago

  • Sprint Focus set to PRC
Actions #5

Updated by Christian Kuhn about 9 years ago

  • Status changed from New to Rejected

-2 to implement a feature that is practically impossible to get right. See my arguments on the related issue on that. This part is task of a different system that monitors the integrity of a system and a standalone typo3 instance can not provide this is a save way from security point of view.

If a dev who has to work on an instance needs to know if a the instance is "vanilla", he should fetch a core from a trusted source and then diff it.

Actions #6

Updated by Benni Mack over 4 years ago

  • Sprint Focus changed from PRC to Needs Decision
Actions #7

Updated by Michael Schams over 4 years ago

Although I understand the benefits of a check if core files have been modified, this should not be done by the core itself.

This would be a pointless exercise from a security perspective. If an attacker manages to tamper with the core files, the attacker is also able to modify the integrity check to hide or obscure his/her activity (and the fact that the core has been modified). Showing a message "the core files are unmodified" (or modified) gives an administrator a (possibly false) impression that the instance is secure.

Therefore, integrity checks should only be executed from the outside.
I have not tested any existing tools against the TYPO3 core files yet, but there is a range of open-source software security and data integrity tools available.
For example tripwire

Actions

Also available in: Atom PDF