I checked both our local hardware store and the pet store for a "cuckoo
sandbox," but they only had regular play sand for children. If I bury the
click crazy people in play sand, will that solve the problem?
I would think that something like if an ALLOWPARTONLY hash is found along
with a second regular hash, that the regular hash wins. The allowpartonly,
or whatever you want to call that flag, just ignores any otherwise
disallowed part, but the regular type allows the whole file, so that wins.
Despite me being a complete hack at programming, I took a look at
ASSP_AFC.pm 5.02. I think I get the general gist of it, but you're right,
very complex.
You seem to do
$self->{SHAisKnownGood} = 1;
return;
in 4 functions isAnExe, isZipOK, get_zip_filelist, and getPDFSum, with that
return prohibiting doing more analysis, exactly how you indicated.
When any of these 4 functions are called again for other parts of the file
or recursively, you have
return if $self->{SHAisKnownGood};
at the top of the function, so that stops any action if a sha match is
already recorded, exactly how you described it would.
isAnExe gets called for *each file/part in a compressed file* right? If
so, then if an office compressed file is being scanned, when it does
isAnExe on vbaproject.bin file couldn't you check the additional parameter
for the SHA like I talked about based on ALLOWPARTONLY (or probably better
to call this something like OnlyPermitThisPart) in the config?
Wouldn't proposed code like accomplish what I'm talking about? I used a
separate array, but a multidimensional array would work too.
if ($knownGoodSHA_OnlyPermitThisPart{$sha}) {
$self->{SHAisKnownGood} = 1;
}
return;
If this matching sha is only supposed to allow *this part* (vs the whole
containing file) if a sha is found, don't set SHAisKnownGood, but still
return as if nothing was detected. After that, wouldn't isAnExe get called
for all of the other parts of the office (compressed) file? If OLE is
detected in a subsequent run of a non-sha matching part, the containing
file still gets rejected even though we already found known good VBA.
Same idea in the other functions. If we have OnlyPermitThisPart,
immediately return from the detection function without setting
SHAisKnownGood. If we don't specifically say OnlyPermitThisPart in the
config, then the current functionality runs: set SHAisKnownGood to 1 and
stop all further checks on the containing file.
This all seems too simple to me, so I must be missing something
significant, but maybe you could use this as a start? Once the sha
exceptions catch on with other ASSP admins, I think there's going to be
demand for this kind of functionality.
_______________________________________________
Assp-test mailing list
Assp-test@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/assp-test
