Let's say I've bought a certificate and signed my Inno Setup installer and the source files with it. Then the installer goes to users who might simply remove the signature which might be against the company's policy. Is there a way to prevent that, so the user won't be able to remove the signature?
An executable is a file as any other. There's nothing you can do to prevent the user from modifying a file on his/hers Windows machine any way the user likes (unless you control the machine). On Windows, the user has a full control. That's both the power and weakness of the platform.
Of course you can make it harder by having the installer itself check if it is signed (and signed with the right signature). But again, nothing prevents the user from removing the check, though it's indeed lot more difficult that just removing the signature.
Related
I know this looks like a dumb question, but I just found out that, last month, something terrible happened to my GitLab instance: someone signed up on it and became admin himself, without my invitation, as I was the only administrator. So he wiped off every internal and/or private project inside of it, groups too (and I don't even know whether he had stolen all of them before erasing or not, I'm worried because they were proprietary code). How did it happen? Does this have anything to do with, since the version was CE-13.3.0? If so, would version upgrading be enough to be safer, or should I make some particular configurations, such as disabling sign up page?
It is best to follow "GitLab instance: security best practices", which does include indeed:
Ensure open sign-up is disabled on your instance.
Open registration is disabled by default on self-managed instances with GitLab 13.6 and above installed.
If new sign-up is enabled and your instance is open to the internet, anyone can sign up and access data.
Administrators who would like to further restrict access on their instance can follow our documentation on how to configure user access.
Regarding the CVE mentioned, follow also "Action needed by self-managed customers in response to CVE-2021-22205", in your case: "CVE-2021-22205: How to determine if a self-managed instance has been impacted" (unless the log events have been wiped out as well).
I am trying in our installer to add a macro that is available to every worksheet. What we presently do in our wix installer is (both 32-bit & 64-bit):
msOfficeApp.Workbooks.Add
msOfficeApp.Workbooks.Open (Session.Property("ExcelMacroLoc") & "AutoTagExcelMacro.xla")
msOfficeApp.Workbooks("AutoTagExcelMacro.xla").RunAutoMacros 1
...
<Property Id="ExcelMacroLoc" Value='C:\' />
<CustomAction Id="AssignExcelMacroLoc" Return="check" Execute="firstSequence" Property ='ExcelMacroLoc' Value='[INSTALLDIR]'>
</CustomAction>
This works sometimes, but not always. Oftentimes we get some or all of the below. What is the best way to tell Excel where this VBA script is and that it's ok to use in any worksheet?
I think the issues/questions are:
Is there anything in this macro (AutoTagExcelMacro.xla) that needs to change (written in 2000)?
Should the file's extension be changed to .xlam? And does that require any other changes?
How do I digitally sign the xla file?
How do I figure out where Excel is installed (to know where to install the macro)?
How do I determine the bitness of Excel (GetBinaryType does not work).
Is there anything else I need to do besides copy the xla file to the appropriate folder?
Also asked on MSDN (I'll post any answer from there here).
" #ProfoundlyOblivious Could you please post an answer telling us how to do each part best - digitally signing, trusted location, etc. and what/where we should tell people to look for macros being disabled? – David Thielen "
Disclosure: I am not an expert in software deployment, my knowledge is limited to the obstacles I encountered sharing my VBA solutions among peers on IT managed networks.
Note: The dialog boxes in your post do not all originate from the same cause. The first relates to security and the others to file availability.
Security
Macros have been, and still are, used in the development and circulating of malicious software. As a result macros are disabled by default and require user interaction to run.
Macro Security Settings
Macros are enabled through the Trust Center, which is accessed through the file menu. These settings are independent for each Office application and some applications may have additional options involving the suppression of a dialog box. Such as Excel where all macros may be disaabled without notification or all macros may be disaabled with notification. There are three basic settings for all Office applications summarized as:
Disable all macros
Disable all unsigned macros
Enable all macros (Not Recommended)
I strongly recommend that one does not enable all macros. It may achieve a desired result but I believe the risk is far too great to warrant the consideration.
Digitally Signed Macros
A digitally signed macro in and of itself simply means the underlying code has not been changed by anyone since last saved by the signer. If the signer's certificate is installed on a computer as a trusted publisher then macros signed with that certificate can run without notification under the requisite macro security setting.
In corporate environments, IT may retain a library of certificates and there may be an established procedure for an internal developer to submit a project for wider circulation, whereafter IT signs the project so it can be run with minimal intervention.
In my experience however, I have found many companies do not have an SOP for this process or that the process is prohibitively onerous. At such times, I turn to self-signed certificates. A self-signed certificate if miraculous for personal development because it provides ample flexibility without incurring the risk if allowing unsigned code to run. The problem, of course, then comes with sharing your code because the recipient will not have your certificate installed. They could install my certificate but my personal preference is that I send an unsigned project and they create a certificate and sign the project themselves. This is an easy step-by-step process that requires no skill beyond the ability to follow instructions.
Trusted Location
A document saved in a trusted location can run macros without notifications. Trusted locations are added in the Trust Center.
By default, XLStart is a trusted location
File Availability
When Excel is opened, it will try to refresh links to other data sources and add-ins. Those files must be open for a successful refresh and a dialog box will appear if the refresh fails.
Based on little more than experience and deduction, I believe this message is often semi-erroneous and driven by either the lack of a time out timer or too short of one. I have tested this with a simple worksheet and a simple add-in. The message pops saying the link could not be updated but it was open and updated by the time I manually check the status of the connection.
In other words, the dialog box was an iritation that served no value.
There is an option that suposedly offers some control over the "Links Could Not Be Updated" window with options along the lines of:
Update links and notify
Update links and do not notify
I have found these settings unreliable and prone to resets from crashes and updates.
To the best of my knowledge, the most assured way if avoiding this type of warning is to install the add-in after Excel is stable and uninstall the add-in before Excel closes. Of course this comes with it's on set of problems including a user perceivable slower loading time.
I would like to know how I can achieve the following:
Have Excel open without the request to "Enable Macros" for an Excel sheet that is distributed as a template and filled in by many, to then come back to a script of mine that wants to read the contents of the Excel sheet (Macros are only there for the users).
Any actions that require me to perform a change to my own installation of Excel (such as adding the file to the trusted docs), won't work, since the computer that runs the script, can be any of a 1000 computers that contains the automated script.
Signing the Excel sheet (something I read here, could solve the issue), is fine, but I would like to know how to go about his, when operating from within an enterprise, governed with a lot of security regulations.
I don't have access to alter the trust center settings, nor can I click the "enable macro's" button every time...
All help is welcome.
The simplest solution is to store the template in a "Trusted Location" - that is a folder on your network where macros are allowed. You can either set the template's current location as trusted, or move the template into an existing trusted location. Your IT dept should be able to set up such a location if they don't already have one enabled in people's profiles. You'll have to talk to your IT dept because it's unlikely your users can alter this setting themselves.
Fortunately noone can do this. If it was allowed to automatically prevent the "Enable Macros" security warning pop-up, this would have been a huge security issue:
However, you may contact the people using the template and ask them to enable all macros from the Trust Centre:
This is how to navigate to the Trust Centre in Excel:
Microsoft Office Button
Excel Options
Trust Center
Trust Center Settings
Macro Settings
Enable or disable macros in Office files
Vityata's solution only works if your enterprise security policy allows trusting network drives. It doesn't work in our environment as our security policy disables trusting network drives.
I handled the issue on a much smaller scale by self-signing the macros and installing my cert on the client's computers. I only have a few clients that use the scripts I write so it's not a big deal for me.
However, to do this at scale would require your IT dept to distribute your cert via their Windows update mechanism. You have to have admin access to your machine and a second as a test platform for this to work.
The steps you would take would be:
Create your self-signed cert.
Sign the macro.
Test it works on another machine by installing your cert on the other machine and running the macro.
Send the cert to your IT dept for them to distribute.
Send the spreadsheet to your clients.
I'm working on an alternative approach of setting our department up as a certificate authority and issuing properly signed certs internally for our own use. We have a plethora of devices that don't have fully qualified domain names assigned to them because the network group doesn't want to deal with the overhead of maintaining thousands of certs. As you might imagine, it's a project to get all the pieces in play so that one person can handle it.
i have a shared access application, i created an accde file for 32-bit machine, when user open the application he/she getting a security warning
is there any way to disable this message from appearing to the users
thank you
You have to set their computer to be a trusted source. In order to get around this issue, you will need to create a Digital Certificate. Digital Certificates are good only on the computer they are created on, so if this database will be used on multiple computers then each one will have to create a Digital Certificate.
To do this, you will need to perform the following tasks:
Click on Start -> All Programs -> Microsoft Office -> Microsoft
Office Tools -> Digital Certificate For VBA Projects (If you don’t
have this, you will need to contact your IT Dept.)
Enter a Certificate Name. Make it obvious like MyProgramName and Click OK
Open the Access database which contains the security warning you want to bypass
Go into the Design View of any Module
Click on Tools -> Digital Signature
Choose your Digital Certificate you created in Step 2
Save and close the database
Re-Open the database. You will now be prompted with a different Security Warning that states the file has been digitally signed.
Check off the “Always trust files from this publisher…” box and click the Open button
All subsequent times you enter this database, you will not be prompted with a security warning.
Note - I wrote the above for our company based on Office 2003. If you're using a more recent version, the instructions may vary somewhat.
other way is following:
click on file and then options
click on trust center and then trust center settings on the right
then click on trusted locations and add new location
browse for the location and save.
that's it.. done.. now no more warnings..
That is a standard warning to indicate the file you are opening has web links and macros.
If you trust the file, just say OK or “Allow”
You can control if this message is displayed: Office button > Excel Options button > Trust Center > Trust Center Settings button (I have no idea why they have this extra button, DUMB DESIGN! )
More Information can be found here
I have an Access database that processes other Access databases. I get OP's error when connecting to one of the other Access databases. To fix the issues, I opened the other Access database and clicked Enabled Content. Then, the Access database is trusted and OP's error doesn't occur when connecting to that Access database from another Access database.
You can create a registry key that will add the directory as a trusted location and will not show the warning anymore. What's nice about this method is that you can easily automate this to happen on the computers where you deploy your app. See method #2 or #3 in this blog: http://www.accessrepairnrecovery.com/blog/fix-microsoft-access-security-notice
And in case the blogs ever gets removed, here is the important bits:
[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Access\Security\Trusted Locations\Location20] “Path”=”C:\Database\”
“Description”=”My Database location”
Explanation about the key:
– The number “14.0” is the version of MS Office. You can change the numbers that represent the version you are executing.
– The “Location20” is a unique name that you assign. 20 can be any number that is not previously used. Other programs include default MS Access wizards, already have used other numbers. But if you want to make more than one path as trusted location, then each location must end up with different number.
– The “C:\Database\” is the physical path that you want to set to be as Trusted Location. You can place any path that you choose here.
By copy and pasting the above coding into a text file and save it with a name such as RemoveSecurityWarning.reg, you can then run the file into your PC’s registry just by making double click on the file.
The best way is to add the location of the document or the document itself to the Trusted Locations in Registry (if you use only Access runtime on client machines, there is no way to add it through the Office application, like you would do in Excel).
Here is the answer:
Adding Trusted Location to Access Run Time
You would need to create a new Location key and add the necessary Path (and Description) strings inside with the appropriate location of your file. This way the nag dialog will be gone and you won't need to worry about certificates.
Shared may mean it is located on a network share. It is not advisable to add a network location to the Trusted locations and you would need to set the additional flag AllowNetworkLocations to 1. I would advise you to copy the Access modules to the user computers, which would also make things better with the speed I believe.
If anybody else have this problem, it happened to me, with a shared file on a network environment, and the simplest solution was to install Microsoft Office service pack 2, even better is having automatic updates for Office turned on. You can find it here.
Not quite sure how to troubleshoot this. I'm maintaining an ASP site, its mostly static, but there's this one include page which brings the menu.
Just recently I replaced some images, but now when I try the site, I get a prompt for a password as if It were looking for something on the local network!
I checked, all image paths are written up correctly, all images are unblocked (a W2k3 safety feature) and all images are set to allow-all on all users ... yet still, I get a password prompt!
Here's a sample page where it happens: http://www.iossolution.com/company/aboutus.asp (Windows only, it seems)
Thanks.
/mp
mauriciopastrana,
Check that the appropriate user has permission on the files in the windows file system. For W2K3 and IIS6 I think that user is typically NETWORK SERVICE.
Also check that the images directory has the intended authentication setup in IIS. You'll likely want to have the "enable anonymous access" checkbox checked and the "Integrated Windows Auth" box checked. You might also need to make sure that the IUSR_SERVERNAME user has access to the images.
Good luck!