Component/Module/Bot code checker initiative The thing that started this ball rolling: a screwup on my behalf in a component I released where I forgot to remove some install check code that sent me a confirmation e-mail after installation. Meanwhile, several other component authors have reacted on the Mambers forum that they too have been using the same confirmation approach for install checks in development and sometimes release phases, and my components have been cleared by independent sources such as ParkWeb Oracle, MyPMS and I've also received constructive messages from a member of the Mambo Development team.
The issue has identified a vulnerability in Mambo
Yesterday I wrote an article on recommended practices before installing a Mambo component to a live site (see my site or the thread), and today I'd like to extend that into a suggestion for a Component/Module/Bot code checker initiative
Yesterday, a discussion evolved on Mambers on how this problem could best be treated at the root: in mambo itself. I'm afraid that as I see it, there is no quick fix for a 100% secure install checker, but I think we can get close.
Practically everyone in the forum agreed that a central component download repository with code review before publishing would actually be the next best thing. But I guess everyone can more or less imagine how much work (not to mention responsibility) that would put on the shoulders of the Mambo repository site administrators.
So I've got an additional suggestion, that could actually be turned into a component or a callable function that can be integrated into the Mambo Core code, or up/download components like remository:
1) a unique ID, combined with a CRC check of the file is indeed undispensable for identifying components and versions in the install XML file. It's just too easy to change the other information in the XML file.
2) A scanning function (callable in a dedicated component, com_install or components like Remository) that checks for:
-Things that must be in a component's code, like valid or die, and a check wether it's not just a commented line or string value, and a "risk level" for each entry if it's missing
-Things that shouldn't be in a component's code, like mosConfig_Password, config.php, and a "risk level" for each entry if it's present
-I also initally thought of things that may indicate malicious code, such as eval() to hide cut-up commands so they wouldn't show up in a regular text search, but I've been informed that you can actually scan pre-processor output PHP code, so that would eliminate this kind of coverup.
Based on the scanning function, a report should be generated with the line numbers of "risk code", that may actually in the case of mail() etc. be completely justified, and a way for the code reviewer to "OK" those justified items in the report, so a realistic risk value can be assigned to every component (and every version).
The repository of all collected "rules and risks" is probably best put in an XML file, with GUIDs for all items, so code can always be scanned against the most recent version of the code rules. This rules files must be retrieved from trusted sites, ideally MamboForge or MamboServer...in short, the equivalent of the approach virus scanners use, but not in proprietary format.
I want to work this out further into table structures and basic code, but I would suggest that the first thing to do would be to compile a list of must-haves, can't-haves and watch-its. I'll submit my list in this thread once I've given this some more thought, and think about table and XML structures.
I'll submit all code and ideas for review here first.
Last edited by active6; 03.12.2004 at 23:41.
|