Aller au contenu

Photo

ActivePerl detected as insecure by Secunia


  • Veuillez vous connecter pour répondre
8 réponses à ce sujet

#1
Sensorie

Sensorie
  • Members
  • 404 messages
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.

#2
Talian Kross

Talian Kross
  • Members
  • 239 messages
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.

#3
Sensorie

Sensorie
  • Members
  • 404 messages
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
Talian Kross

Talian Kross
  • Members
  • 239 messages
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
Sensorie

Sensorie
  • Members
  • 404 messages
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
FollowTheGourd

FollowTheGourd
  • Members
  • 572 messages
double post

Modifié par FollowTheGourd, 02 décembre 2009 - 12:04 .


#7
FollowTheGourd

FollowTheGourd
  • Members
  • 572 messages
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*

Modifié par FollowTheGourd, 02 décembre 2009 - 12:16 .


#8
Jab0r

Jab0r
  • Members
  • 406 messages
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
FollowTheGourd

FollowTheGourd
  • Members
  • 572 messages
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.