Secuina is detecting a version of 5.6.1.633 for perl.exe, located at Dragon Age\\tools\\ResourceBuild\\Processors\\perl\\perl.exe.
Apparently the latest (and presumably secure) version is 5.6.1.638, but I'm not sure if updating will break functionality.
ActivePerl detected as insecure by Secunia
Débuté par
Sensorie
, nov. 30 2009 01:41
#1
Posté 30 novembre 2009 - 01:41
#2
Posté 01 décembre 2009 - 02:25
I seriously doubt Bioware is trying to infect your computer, so why not just add it to your exclusion list?
Besides, this is really a Secuina problem and their failure to update their own detection routines to account for this version of Perl.
Besides, this is really a Secuina problem and their failure to update their own detection routines to account for this version of Perl.
#3
Posté 01 décembre 2009 - 07:12
It's more to do with BioWare packaging an outdated (and presumably) insecure version of ActivePerl, leaving it open to possible exploitation. Secunia have obviously accounted for this particular version of Perl, otherwise it wouldn't have been detected as insecure and flagged as in need of updating.
#4
Posté 01 décembre 2009 - 08:28
Do you even know what Perl is? By definition, ALL versions of Perl are "insecure." It's just a scripting language. Deeming it "insecure" is just like deeming gcc or Visual C++ "insecure." With them, OF COURSE you can wreak havoc on a system; that doesn't mean BioWare does, though.
#5
Posté 01 décembre 2009 - 09:34
Of course it's possible for any installation of Perl to be deemed insecure due to several theoretically exploitable functions, but for some reason 5.6.1.633 (the version that comes with Dragon Age) is flagged as insecure, whilst 5.6.1.638 (the suggested update) is not, although neither are even the latest release. I don't know where you're getting the idea that I'm implying BioWare could be deliberating exploiting any vulnerability.
#6
Posté 01 décembre 2009 - 02:32
double post
Modifié par FollowTheGourd, 02 décembre 2009 - 12:04 .
#7
Posté 01 décembre 2009 - 02:40
Updating to to .655 (Edit: 638 actually) probably won't break anything (but it might, and you might break something trying to update it), but it's probably not much of an actual risk either unless you're using untrustworthy program data or it's running on a server where you're letting other people do the same.
According to the changelog for 635 (the build after 633):
Fixes for Security Issues
* On Linux, the crypt() builtin did not return consistent results. This has been corrected.
* The reval() and rdo() methods in the Safe module could be subverted into executing unsafe code by the callee. This problem has been corrected.
Build 638 fixes some potential buffer overruns (which I'd consider a potential security issue, but whatever) and some other minor stuff...
*shrug*
According to the changelog for 635 (the build after 633):
Fixes for Security Issues
* On Linux, the crypt() builtin did not return consistent results. This has been corrected.
* The reval() and rdo() methods in the Safe module could be subverted into executing unsafe code by the callee. This problem has been corrected.
Build 638 fixes some potential buffer overruns (which I'd consider a potential security issue, but whatever) and some other minor stuff...
*shrug*
Modifié par FollowTheGourd, 02 décembre 2009 - 12:16 .
#8
Posté 01 décembre 2009 - 06:14
If it's suggesting updating to .638 (rather than .635), then I expect that it's the buffer overruns that it's suggesting are a security problem.
#9
Posté 02 décembre 2009 - 12:05
Yeah, I meant to write update to .638. Somehow I also managed to double post when editing...
But first it'd be interesting to know what perl is even used for in the toolset before worrying about it.
But first it'd be interesting to know what perl is even used for in the toolset before worrying about it.





Retour en haut






