can i still use Win32::OLE with active Perl 64 bit?

perlynewby has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Can I still use Win32::OLE with active Perl 64 bit? by davies (Monsignor) on Feb 03, 2022 at 20:14 UTC
Yes. I asked a similar question (What Windows 64 bit traps are out there?) when I was upgrading & the answers I got are still helpful. Regards, John Davies	[reply]
Re: can i still use Win32::OLE with active Perl 64 bit? by pryrt (Abbot) on Feb 03, 2022 at 20:21 UTC
Well, Strawberry Perl 5.12.0 ships with Win32::OLE v0.1709 by default, so it obviously works with that version of Perl. The cpantesters Win32-OLE Matrix shows the last version of the module that has submitted a passing test with each version of Perl. Even the most recent 0.1713 works on Perl v5.12.2, so my guess is that 5.12.0 should also install it fine (and that it's just no one is bothering to smoke-test on 5.12.0 when 5.12.2/3 both exist). edit: sorry, I didn't see that Strawberry 5.12.0 only shipped as 32bit. It appears 5.12.3 was the first that Strawberry shipped with 64bit. But still, assuming you have a 64bit 5.12.0 successfully working, with a full build environment, I think it likely that Win32::OLE is going to work for you.	[reply]
Re: can i still use Win32::OLE with active Perl 64 bit? by syphilis (Archbishop) on Feb 03, 2022 at 23:56 UTC
So, before I download that, I'd like to know IF this Win32::OLE utility still will work for a 64 bit/Perl 5.12.00? There's an Issue with Win32-0LE-0.1712 (and earlier) wrt 64-bit MS Outlook. Sounds like that won't interfere with your usage, but it's best if you get the latest version (0.1713), anyway. Cheers, Rob	[reply]
Re: can i still use Win32::OLE with active Perl 64 bit? by cavac (Prior) on Feb 04, 2022 at 14:23 UTC
the company only allows active Perl 5.12.00 So your company IT prefers to use a Perl version with known security problems (including remote code execution and stuff) because they don't want to risk that someone possibly, maybe, on the-off-chance of the moonphase being wrong, having to go in and fix a couple of bugs in old scripts? I think your company IT is facing a classic XY problem. They are asking "Upgrading Perl may result in some additional work, so keeping the old version is the best option we have. What do we have to do to keep this old version running?", when really, the question should be (in my opinion): "What do we have to do to make sure we have the latest security updates". Just in case, send them the link to the CVE database for Perl in writing. You don't want to be the one who gets the blame if the fit hits the shan, so to speak: https://www.cvedetails.com/vulnerability-list/vendor_id-1885/Perl.html. Maybe also clarify that there are quite a few nasty things that have since been fixed. For example: CVE-2012-5195: Heap-based buffer overflow in the Perl_repeatcpy function in util.c in Perl 5.12.x before 5.12.5, 5.14.x before 5.14.3, and 5.15.x before 15.15.5 allows context-dependent attackers to cause a denial of service (memory consumption and crash) or possibly execute arbitrary code via the 'x' string repeat operator. CVE-2013-1667: The rehash mechanism in Perl 5.8.2 through 5.16.x allows context-dependent attackers to cause a denial of service (memory consumption and crash) via a crafted hash key. CVE-2014-4330: The Dumper method in Data::Dumper before 2.154, as used in Perl 5.20.1 and earlier, allows context-dependent attackers to cause a denial of service (stack consumption and crash) via an Array-Reference with many nested Array-References, which triggers a large number of recursive calls to the DD_dump function. CVE-2018-6913: Heap-based buffer overflow in the pack function in Perl before 5.26.2 allows context-dependent attackers to execute arbitrary code via a large item count. Depending on what you are using Win32::OLE for, an attacker could basically create an Excel/Word/Powerpoint file that makes your Perl scripts execute arbitrary code like encrypting your data and then asking for some Bitcoins... `perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'`	[reply] [d/l]
Re^2: Can I still use Win32::OLE with active Perl 64 bit? by davies (Monsignor) on Feb 04, 2022 at 16:14 UTC
It's worth adding to your good points that the vulnerability you describe in your last paragraph exists with any versions of Perl, Win32::OLE and/or MessOffice. I have demonstrated adding code to a spreadsheet in RFC Tutorial: Adding and extracting VBA to and from Excel files. What that code does is unrestricted. Amending it for anything else that runs VBA is trivial. Regards, John Davies	[reply]
Re^2: can i still use Win32::OLE with active Perl 64 bit? by perlynewby (Scribe) on Feb 10, 2022 at 00:25 UTC
You're undeniably right. I read the vulnerabilities and I was alarmed so I forwarded the link to the IT dept; I do not think the IT guy opened the document; he only replied, "thank you" to that email I have not heard from him again... until today New argument for not loading the CPAN module WIN32::OLE is that it is not set for Linux. He said WIN32::OLE binds to Window when running from the Linux side but our Linux servers aren't configured and will not work. He is closing my request to mount the CPAN module that edits Windows Docx files! I've been nothing but nice to the IT guy but at every turn he denies me. My opportunity to write perl code for this application to replicate earlier orders is being thwarted by the inability to convince IT that the WIN32::OLE written for Perl is critical to my code" Any suggestions on any other language that can take a docx file and edited ?? I know this is a Perl forum but I've been kneecapped from using Perl at every turn. And there is no way I am editing 100's of docx to create virtual docx in a new format	[reply]