|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
|
|
Introduction.
|
|
This paper will discuss how you can use Office 2000 to guard against macro viruses.
Office 2000 has introduced digital signatures to help users distinguish legitimate code from undesirable and viral code. If you open an Office document and see a macro security warning with digital signature information, you can feel reasonably confident that the person (or corporation) signing the macros wrote them. You can choose to trust all macros signed by this person by checking the Trust all macros from this source checkbox. From then on, Office will enable the macros without showing a security warning for any document with macros signed by this trusted source.
Office 2000 silently disables non-signed macros when the new Office 2000 Security Level feature is set to “High.” In fact, the default security setting for Word 2000 is "High." By removing the chance that a user “accidentally” enables a virus-infected document, the high security level helps reduce the spread of macro viruses. If all legitimate macros are digitally signed, then users do not even need to see the security warning without digital signature information.
We are hoping with the advent of this new technology that you will expect legitimate macros to be signed. If you see a security warning in Office 2000 without digital signature information, you should seriously consider the possibility that the macro contains a macro virus.
If you use the Office 2000 digital signature features as advised in this white paper, you will not see annoying security warnings for any of the macro solutions that you write or use. You will only see a security warning when it is justified; that is, when you open a document with unexpected macros or viruses.
Office 2000 also enables users to specify a third party virus scanner to scan every file before it is opened in Word, Excel or PowerPointÒ. If users update their virus scanners regularly, they may feel sufficiently safe to run under "Low" security level for these applications and hence avoid all Office security warnings. This method avoids unnecessary security warnings for non-viral macros. It actually allows users to be alerted only when a known virus appears. Users are not protected from new viruses that their 3rd party virus scanners cannot identify.
Always be sure to remain skeptical of every unsigned macro you enable. Once you let one Trojan horse into your system, your defenses can be completely disabled. A Trojan horse is something that may appear friendly or desirable, but actually contains malicious machinations (possibly viral code) that activate once behind your defensive wall. Office 2000 has very little defense against malicious code that you allow to run on your machine. Once that malicious code is allowed to run on your machine, it will run with your privilege rights, and it may reset your security level, or install itself to become a Trusted Source. The features described in this paper work to help you prevent malicious code from running at all.
The Custom Installation Wizard (available in the Office 2000 Resource Kit at http://microsoft.com/office/ork/2000/default.htm ) enables the administrator to specify these security settings for their users when Office 2000 is installed. The administrator may also set security policies to help reduce the spread of macro viruses.
Refer to Introduction to Code Signing (http://msdn.microsoft.com/workshop/security/authcode/intro_authenticode.asp
) for an explanation of
the principles and technology used for any Authenticode
digital signature.
For a general overview of information technology security and for ideas on where else to go to learn more, read on. To delve into these areas more deeply, visit the Microsoft Security Advisor ( http://www.microsoft.com/security/default.asp ) Web site.
The Microsoft Office 2000 products contain other security assistance and tools. For example, you can encrypt the body of an e-mail message; you can "protect" documents in Word so that the types of changes readers can make are restricted; you can limit access and changes to worksheets in Excel; and you can secure Access databases using passwords and user-level security. To find out how to enable these tools in the products, type security in the Office Assistant.
Office Update ( http://officeupdate.microsoft.com ) also provides information about recently released security updates for Office.
The following Office applications include security level and digital signature features for Microsoft Visual BasicÒ for Applications macros: Word, Excel, and PowerPoint. Access, OutlookÒ, FrontPageÒ, Publisher, and PhotoDrawÔ do not support Security level and digital signature features for Visual Basic for Applications macros. Access and Outlook do support security level and digital signature features for COM (Component Object Model) add-ins though there is no UI (user interface) for this support.
Office 2000 digital signature features depend on a WindowsÒ operating system feature called AuthenticodeÔ technology. The only Office 2000 platform configurations which don’t include Authenticode technology, and therefore won’t support Office 2000 digital signature features, are installations for users of Windows 95 or Windows NTÒ 4.0 SP3 platforms that have Microsoft Internet Explorer 3.0.
In case you are wondering about the details: Authenticode technology is included in the newest versions of Windows—Windows 98 and Windows 2000 Professional. Authenticode is also distributed with Microsoft Internet Explorer version 4.0 or later, and also with Microsoft Internet Explorer 5 and the Windows Web Browsing Components which are included in Microsoft Office 2000 Setup. See the Office Resource Kit at http://microsoft.com/office/ork/2000/default.htm for details about configurations for which Office 2000 will force installation of the Windows Web Browsing components.
Let’s start with a general overview of digital signatures.
Digital signatures and certificates of authenticity can be applied to executable programs, ActiveXÒ controls, or Office Visual Basic for Applications macros. They can provide you with both the assurance that what you are about to use comes from the company it says it comes from and that it has not been tampered with. As we use the Internet more and more to publish Office documents, ActiveX controls or other programs, the question of trustworthiness looms large.
You can think of a digital certificate as the electronic counterpart of an identification card, such as a driver's license or passport. The process for validating a digital certificate is similar to the process used to issue a physical ID card. A certification authority validates information about software developers and then issues them digital certificates. The digital certificate contains information about the person to whom the certificate was issued, as well as information about the certifying authority that issued it. Additionally, some certifying authorities may themselves be certified by a hierarchy of one or more certifying authorities, and this information is also part of the certificate. When a digital certificate is used to sign programs, ActiveX controls, and documents, this ID information is stored with the signed item in a secure and verifiable form so that it can be displayed to a user to establish a trust relationship.
Digital certificates use a cryptographic technology called public-key cryptography to sign software publications and to verify the integrity of the certificate itself. Public-key cryptography uses a matched pair of encryption and decryption keys called a public key and a private key. The public-key cryptography algorithms perform a one-way transformation of the data they are applied to, so that data that is encrypted with the private key can only be decrypted by the corresponding public key. Additionally, each key uses a sufficiently large value to make it computationally infeasible to derive a private key from its corresponding public key. For this reason, a public key can be made widely available without posing a risk to security.
In essence, a digital signature is the public certificate plus the checksum/hash of the signed data encrypted by the private key. The “checksum” or hash is a number generated by a cryptographic algorithm (such as MD5, SHA1) for any data that you want to sign. The interesting feature of this algorithm is that it is very difficult to change the data without changing the resulting checksum/hash value. So, by encrypting the checksum/hash value instead of the data, a digital signature allows the end user to verify the data was not changed, with a minimal number of bytes.
Let’s review this more concretely.
I get a digital certificate from a certificate authority. I keep the private key of this digital certificate on my machine. When I sign some data, my software computes a checksum for the data and then encrypts the checksum with my private key. My software stores that encrypted checksum and my public digital certificate together (that’s a digital signature) in the data’s file. That process is called “digitally signing” data. The software does the work so that I just install a digital certificate, and choose the command to sign my data file.
Now when you want to check the digital signature on this data file, your software can read the digital certificate, which contains my name, and the certificate authorities guarantee that I am who I say I am. Next, your software decrypts the encrypted checksum using the public key in the digital certificate to do the decryption. Then your software computes the checksum of the data in the file. If that computed checksum matches the decrypted checksum, then you can be sure that someone with the private key signed this data. If I guarded my private key well, the only person with access to the private key would be me. This end of the process is called “verifying a digital signature.” The software will do all this work, so that you only see the results of the verification process, which lists the name of the person in the digital certificate, and whether or not the signature seems valid for the data.
To further reduce the possibility that someone will derive a private key from the public key in a digital certificate, the certifying authority issues the key pair with an expiration date so that they must be replaced periodically. Any signature applied after the digital certificate expires is invalid. To assure that a signature was applied before the certificate expired, the certifying authority can timestamp a digital signature. Essentially, that means taking the signature, adding the current time and signing them together. When a digital signature is timestamped in this way, the software can verify that the signature was applied while the certificate was still valid.
If and only if the owner of the certificate keeps the private key secure can end users be sure that signed data has come from that owner. In addition, if users believe that the owner would sign only legitimate and safe executables, then they should feel it is safe to run the executables, and therefore include the digital certificate in their lists of trusted sources.
If the owner of the certificate stores the private keys on a machine, and leaves the machine logged on with their privileges, someone could walk up to the machine and start signing macros with the certificate. The owner can prevent this by using various methods to protect this private key. For instance, Microsoft Internet Information Services Certificate Server allows users to create certificates that require a user-specified password before the private key is used. Hardware encryption tools can store the private key in a smartcard. Then the physical smartcard is required to sign. The smartcard can be physically locked up, or simply carried on the person (as security needs dictate).
Certificate owners should guard their private keys carefully. Their reputations are on the line.
A key difference between typical digital signature applications and Office 2000 is that Office 2000 only signs the Visual Basic for Applications macro project contained within the Office file. Office 2000 does not sign any document content, such as the body text, the spreadsheet data, slide content, or any formatting. Therefore users may use a document customized with macros, enter or modify the document and resave without disturbing the macro digital signature. The user will have the reassuring benefits of a macro digital signature, as long as the user (or some virus) does not change the Visual Basic for Applications macros.
To take advantage of the benefits of macro digital signatures, Office 2000 introduces security levels. Medium security level provides the user with a choice to enable or disable the macros on a file-by-file basis. High security level only allows signed and trusted code to run. Low security level turns off all macro security warnings in Office. You can set the security level with the Security dialog in the Tools/Macro menu.
When opening a file with macros under medium security, a security warning offers the user a choice between enabling or disabling macros. The Office 2000 Medium Security Warning dialog has digital signature information, if it is available for the file being opened. This security level allows existing Office 97 solutions, which are not yet signed, to be enabled. Once a user chooses to trust all macros from a source, Office 2000 on medium security will automatically enable signed macros from that trusted source—without any security alerts.
Under high security, Office 2000 silently disables unsigned macros. This helps avoid accidental enabling of potentially dangerous macros when users carelessly dismiss the Security Warning dialog with the Enable Macros button. To help fight the larger number of Word macro viruses spread through documents, Word 2000 is set to high security level by default. Under high security, a security warning is shown for digitally signed macros that have not been previously added to the Trusted Sources list. This allows users the opportunity to inspect the digital certificate, and if they choose to trust all macros from the source, they may then choose to Enable Macros. The Enable Macros button is disabled until the user decides to check the Always trust macros from this source checkbox.
Low security is useful for the customer who has installed the latest version of a virus scanner and the most current virus signature files for that program and feels absolutely confident this virus scanner will catch all viruses.
Note Microsoft recommends using anti-virus software that is certified by ICSA, Inc. ICSA is completely independent. ICSA shares vital security information with security product manufacturers, developers, security experts, academia and corporations. For more information, refer to the ICSA Certified Anti-Virus Products Web site at http://www.icsa.net/services/consortia/anti-virus/certified_products.shtml .
When the user checks the Always trust macros from this source checkbox in the Security Warning dialog, this digital certificate is added to the Visual Basic for Applications Trusted Sources list. You can see this list in the Tools/Macro/Security dialog in the Trusted Sources tab. You may use that tab dialog to remove certificates from the Trusted Sources list. You can only add sources to this list by opening a file signed by the source and choosing the checkbox (because Office needs to read unique identifiers from the digital certificate stored in the document).
The Office 2000 Trusted Sources list is separate from the Microsoft Internet Explorer list for silently downloading and running ActiveX controls. However, they share the same root certificate authority trust mechanism. So, distribution of root certificates can be managed for Internet Explorer and Office with the same tools.
In Office 2000, the Trusted Sources list is kept in the Windows registry. To get more security for this list, use the Windows NT administrator lockdown features described later in this paper.
Older versions of Office always enable the macros in installed add-ins and templates. We strongly recommend that users who want Security Warnings to upgrade to Office 2000.
The criteria for being an “installed” add-in or template vary slightly in each Office 2000 application that has digital signature features. In Word, templates in the Template directory and files in the Startup directory are considered installed. In Excel, files in the XLStart directory and add-ins registered in Tools/Add-ins… are considered installed. In PowerPoint, registered PowerPoint add-ins and templates in the Template directory are considered installed. In Word, Excel and PowerPoint, registered COM add-ins are considered installed.
Office 2000 offers the user an option to treat installed add-ins and templates with the same security level used when normally opening a document file. This option is controlled by the Trust all installed add-ins and templates checkbox in the Trusted Sources tab of the Security dialog under the Tools/Macro menu in each Office application (Word, Excel, and PowerPoint). This checkbox is selected by default. If you clear this check box, security warnings are applied to all files, including add-ins and templates, according to the current security level.
You may use this option to select exactly what VBA macro code can be run. After un-checking this checkbox, you can digitally sign your add-ins and templates, and then trust your digital certificate. Then you will not see security warnings for those add-ins and templates, but you will see warnings before Office loads any other file with macros.
The Trust all installed add-ins and templates checkbox option also applies to the installed DLL-style add-ins for each application; including COM Addin, XLL, and WLL styles.
The developers of add-ins and templates should digitally sign their work. However, if they do not, you can sign the files for them. You can sign protected VBA projects as long as you can save the file. Signing does not imply you own the file. It just guarantees the authenticity. You probably want to ensure what you sign is virus free before you stake your name on it. See “How to Sign Your Macros” or “Signing DLL’s” below for details.
Some corporate information system administrators would like to exert control over their user’s security settings. Using the Custom Installation Wizard (CIW), administrators can change Office setup to default to a particular security level for each application. [For more detailed instructions for using these Office administration tools, see the Office Resource Kit.]
Administrators can use the Policy Editor User Interface (UI) to set the security level for Word, Excel or PowerPoint. They can also set the Trust all installed templates and add-ins checkbox for each application using this UI.
To set the Trusted Sources list for the user, do the following:
1. Setup a sample user’s machine
2. Choose to trust the sources you want your end users to trust by doing the following for each source you want to trust:
a. Open a document signed by the certificate you want to add to the Trusted Sources list
b. Check the Always trust macros from this source checkbox in the security warning dialog. This source will then be added to the Trusted Sources list in the registry.
3. You can use the Profile Wizard to capture the Trusted Sources list from this machine. Or you can find the registry key values in the location below.
HKEY_Current_User\Software\Microsoft\VBA\Trusted
4. Use that set of registry key values in the Custom Installation Wizard.
For your reference, here are the actual registry keys used by Office 2000 to store the user’s security settings.
The Security\Level value code is as follows: 1 is Low, 2 is Medium, 3 is High. The Security\DontTrustInstalledFiles value code is: 0 is False, 1 is True. You will not find these keys written to the registry if the user has not changed them from the default setting.
Since these security settings are stored in the HKEY_Current_User branch of the registry, the end user can change his security settings as he desires. That also implies that if the end user lets malicious code run on his machine, the malicious code can change the security settings to make it even easier for it to run later.
Some corporate information system administrators would like to exert greater control over their corporate security. When users are running Office 2000 applications on Windows NT 4 and Windows 2000 Professional, an administrator can lock down the security settings that are set in the Tools/Macro/Security dialog. To do this, Office takes advantage of an OS security feature that disables write privileges to the HKEY_Local_Machine branch of the Windows Registry. If only administrators or “power users” are granted read/write privileges to HKEY_Local_Machine, Office 2000 will read security settings from this branch of the registry first, and if it finds a setting there, it will use that setting instead of the parallel HKEY_Current_User setting. So when a user is logged in to an account that does not have rights to write to HKEY_Local_Machine, then neither that user nor a virus can change Office 2000 security settings.
NT4 requires SP3 for this OS security feature. The HKEY_LOCAL_MACHINE registry section on NT4 SP3 (or newer) can be manually locked down following the steps in Appendix A. Windows 2000 Professional is automatically setup to lock down all users that are merely members of the User group (not members of the Administrator or “Power User” groups). Windows 95 and 98 do not support this OS security feature.
Here are the HKEY_Local_Machine registry keys that control the security settings that administrators may want to lock down.
The path of these security registry keys in HKEY_Local_Machine matches the path of the subservient registry keys in HKey_Current_User.
If the HKEY_Local_Machine\Software\Microsoft\VBA\Trusted registry key exists, then the digital certificates listed there will be the only trusted sources for all users on the machine. Office will ignore any digital certificates listed at HKEY_Current_User\Software\Microsoft\VBA\Trusted. Office will gray out the Always trust macros from this source checkbox in the Security Warning dialog. If the administrator does not want any user to have any trusted sources, he should create a never-to-be-used digital certificate, and put that into the HKEY_Local_Machine Trusted list. To help the user see why he cannot remove any trusted sources, the administrator can name the unused certificate to indicate the trusted sources list is locked down.
Here’s an example of the registry key that would add a non-existent source named “No certificate will be trusted. - InfoServices” to the Trusted Sources list.
[HKEY_LOCAL_MACHINE\Software\Microsoft\VBA\Trusted]
"No certificate will be trusted. - InfoServices" = hex:d3,0f,d6,00,91,21,bf,51,7e,60,48,a2,99,ba,25,00,b7,96,08,01
If the administrator wants to allow the user to add trusted sources, he should not set any trusted source in HKEY_Local_Machine. Instead, he should use a Windows logon policy that would add trusted sources in HKEY_Current_User. Those trusted sources will be added during each Windows Logon. Then the end user may still add new sources to his HKEY_Current_User Trusted Sources list, and unlike the situation when there was something in HKEY_Local_Machine’s Trusted list, these will not be ignored. If the administrator uses this policy (instead of setting HKEY_LOCAL_MACHINE’s Trusted list, the administrator cannot prevent the user from deleting the Trusted Sources set by his administrator.
After Office is installed, Office applications will never write to HKEY_Local_Machine security settings. If the user uses Office UI to change the security settings (through the checkbox in the Security Warning, or Tools/Macro/Security dialog), Office will attempt to write to HKEY_Current_User, only if the HKEY_Local_Machine version of that key does not exist. The user may attempt to change his security settings, but the user will see that the application ignored his changes when he reenters the Tools/Macro/Security dialog.
By using the system policy template files (.adm) available in the Microsoft Office 2000 Resource Kit with the System Policy Editor you can actually secure the Office 2000 settings in HKEY_Current_User on Windows 2000 Professional so that the user cannot tamper with these policy settings. However, the systems policy templates do not provide control over the Trusted sources list, nor the XLM on High security registry settings (see below). So for simplicity, the administrator may choose to control these security settings all together through the Custom Installation Wizard or by using Windows NT logon policy scripts.
If the administrator wants to completely disallow any user from running any VBA macros or addins at all, the administrator would install Windows 2000 Professional or Windows NT4 SP4. Then assuming this is to be rolled out to multiple users, the administrator would customize Office 2000 setup to include these registry keys:
HKEY_Local_Machine\Software\Microsoft\Office\9.0\Excel\Security\Level=3
HKEY_Local_Machine\Software\Microsoft\Office\9.0\Word\Security\Level=3
HKEY_Local_Machine\Software\Microsoft\Office\9.0\PowerPoint\Security\Level=3
HKEY_Local_Machine\Software\Microsoft\Office\9.0\Outlook\Security\Level=3
HKEY_Local_Machine\Software\Microsoft\Office\9.0\Access\Security\Level=3
HKEY_Local_Machine\Software\Microsoft\Office\9.0\Excel\Security\DontTrustInstalledFiles=1
HKEY_Local_Machine\Software\Microsoft\Office\9.0\Word\Security\DontTrustInstalledFiles=1
HKEY_Local_Machine\Software\Microsoft\Office\9.0\PowerPoint\Security\DontTrustInstalledFiles=1
HKEY_Local_Machine\Software\Microsoft\Office\9.0\Outlook\Security\DontTrustInstalledFiles=1
HKEY_Local_Machine\Software\Microsoft\Office\9.0\Access\Security\DontTrustInstalledFiles=1
HKEY_Local_Machine\Software\Microsoft\VBA\Trusted\"No certificate will be trusted. - InfoServices"=hex:d3,0f,d6,00,91,21,bf,51,7e,60,48,a2,99,ba,25,00,b7,96,08,01
These keys can be added to a Office 2000 setup file using the Custom Installation Wizard (CIW). See the Office Resource Kit for details about using CIW.
Microsoft Excel 4 style macros (XLM) cannot be digitally signed. Excel cannot fully disable XLM macros. Therefore, Excel cannot allow workbooks containing XLM to load at all on High security. Unfortunately, some corporations have applications using XLM, and even some add-ins shipped with Excel still use XLM. If possible, we recommend you convert your XLM solutions to VBA so that they may be digitally signed. Then your users may use high security and still work with these custom solutions.
We understand that some corporations will want to allow XLM to run as an exception on High Security. Excel 2000 has an option to make this exception on High Security. The end user will get a warning about the macros and would be allowed to open the workbook anyway. This option depends on the end user to know a virus is not in the XLM, while preserving the High security feature for VBA macros. The only benefit of running with this option is that you won’t get security alerts for workbooks with only unsigned VBA. That will help reduce Excel VBA viruses.
Creating this “XLM” registry DWORD value below will activate this option.
HKEY_Local_Machine\Software\Microsoft\Office\9.0\Excel\Security\XLM=1
Deleting this value will defeat this option and return to the default behavior.
First, you need to get a digital certificate. One option is to get a fully certified certificate from a certificate authority. Both individuals and commercial entities can obtain a commercially authenticated certificate for their code. To learn about the application process and requirements, see Introduction to Code Signing at the Microsoft AuthenticodeÔ Web site. A list of Certificate Authorities is provided on http://officeupdate.microsoft.com/office/redirect/fromOffice9/cert.htm
A Certificate Authority can issue you a digital certificate for code signing for a fee. Be sure to get a digital certificate that can sign code with Microsoft Authenticode (Verisign calls this Class 2 or 3; Thawte calls this Developer Certificates), not one that can only sign email. If you try to use a digital certificate that is not authorized to sign code, Office will tell the end user that the digital certificate is not trustworthy. The Certificate Authority will do an in-depth identification check before issuing a digital certificate for signing code.
Alternatively, a company may choose to use the Microsoft Certificate Server to create digital certificates for internal use. Microsoft Certificate Server allows a company to act as the certificate authority for their employees. When using Certificate Server to issue certificates for signing VBA, be sure to issue them enabled for “code signing.” The company should install the root certificate on all machines in the company. That will allow every machine to verify a company-issued certificate.
You can create your own certificate for personal use or testing purposes with the SelfCert.EXE tool provided in Office 2000. This tool is detailed below.
To sign VBA macros, open the document or template that contains the macros you want to sign, then open the Visual Basic Editor, select the VBA project you want sign in the Project Explorer, and then choose the Digital Signature command on the Tools menu. Click the Choose button. The dialog that comes up is provided by the Windows operating system and allows you to choose a digital signature from your “My” Certificates store. The Windows OS stores all digital signatures, for which you have the private key, in the “My” store. For Windows 98, and Windows NT4 SP4, the “My” certificate store is implemented in the registry in the \HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates\My\Certificates store.
Once you choose a certificate and click OK in the Digital Signature dialog, save your file. This marks your project for digital signing. The digital signing process actually takes place at save time. You may make any changes you’d like to the VBA project. When you save, your private key will be used to sign the VBA project. To encourage your use of this feature during development, Office will automatically try to re-sign projects that were signed. If you do not have the private key, Office will warn you this and save without a signature.
If you used a password to protect your private key, you will be asked for the password at save time. If you did not intentionally change the VBA project, or add ActiveX controls (which can change the VBA project) you should make sure a virus did not change the project for you. Run a virus scanner, or if you use source control tools, look at the diffs.
If you already have a digital certificate from a certificate authority and the certificate is stored in SPC and PVK files (currently Thawte and Verisign Class 3 certificates are delivered this way), you will want to use the PVKIMPRT.EXE utility provided on http://Officeupdate. This utility will place a copy of your private key and certificate into the “My” certificates store, and thus become visible to and usable by Office 2000.
Office 2000 provides a tool to generate an unauthenticated digital certificate. This unauthenticated certificate will allow you to sign your own macros, and to trust this digital certificate so that all macros you sign will not generate a security warning. This type of certificate is not validated by a certifying authority. This is for your own information only. No one else will accept it as real certificate since this certificate is not authenticated, and the user will see a warning not to trust it. Because you know this is your certificate, and you know you are the only person that can use the private key, you can feel safe to trust the VBA macro code that is signed with this unauthenticated certificate anyway.
On the other hand, if you ever see the security warning “This publisher has not been authenticated and therefore could be imitated. Do not trust these credentials.” and this is not your certificate, then you should assume this certificate was forged.
This is a source that you probably do not want to trust.
A malicious virus might be digitally signed by a digital certificate by the name of “Microsoft Corp.” However, the security warning will warn you that this is NOT an authenticated certificate; and therefore the certificate cannot really be from Microsoft.
Here’s how to use the utility provided by Office 2000.
· Go to the Control Panel and double-click Add/Remove Programs.
· On the Install/Uninstall tab click Microsoft Office, and then click Add/Remove.
· Click Add or Remove Features from the Office Setup window.
· Then select Digital Signature for VBA projects in the Office Tools category and set it to Run from My computer.
· Click Update Now to finish the installation.
· Then find and run the SelfCert.EXE file in the c:\Program Files\Microsoft Office\Office directory.
· This displays a window where you can type your name and then hit enter.
This will create a digital certificate for code signing with that name and put it into the “My” certificate store.
If you write VBA macros for other users, you may want to use 2 digital certificates. Create one unauthenticated certificate for your daily work. Name this certificate “Do Not Trust Me, Goofy”. You can feel confident that you wrote macros signed with this certificate. But you don’t have to worry as much about accidentally sending out viruses signed by this certificate. Reserve your authenticated digital certificate for signing your work just before sending it out to other users. Run virus checks, and source code reviews before sending out files signed with this digital certificate. Do not expect to be prompted for the password on your authenticated certificate — except when you finalize that code.
COM add-ins and other DLLs may be digitally signed using the Windows Platform SDK tool SignCode.EXE. After installing that SDK, you would execute a command line such as:
SignCode –cn “Microsoft Corp” MyCOMAddin.DLL
Please refer to the Windows Platform SDK for more information about signing DLLs.
Microsoft Internet Explorer 4.0 and 5.0 Certificate dialogs allow you to export the certificate and it’s private key into a PFX file (a standard certificate storage file). This may be useful to move a certificate to another machine, or for backup purposes. You can use the Internet Explorer Security UI.
· Start Internet Explorer 5.
· On the Tools menu, choose Internet Options.
· On the Content tab, choose the Certificates button.
· In the Personal tab, select your certificate.
· Choose the Export button.
· Follow the instructions in the Certificate Manager Export Wizard.
· Start Internet Explorer 4.0
· On the View menu, choose Internet Options.
· On the Content tab, choose the Personal… button.
· In the Client Authentication dialog box, select your certificate.
· Choose the Export button.
· Choose your password and file name.
· Choose OK.
You can import the PFX file with the Internet Explorer Security UI in the Tools/Internet Options dialog.
· Start Internet Explorer 5.
· On the Tools menu , choose Internet Options.
· On the Content tab, choose the Certificates button.
· Choose the Import button.
· Follow the instructions in the Certificate Manager Import Wizard.
· Start Internet Explorer 4.0
· On the View menu, choose Internet Options.
· On the Content tab, choose the Personal… button.
· Choose the Import button.
· Type your file name and password.
· Choose OK.
To reduce the likelihood that a malicious user can derive a digital certificate’s private key from its public key, a commercially obtained digital certificate expires after one year. Office will not allow you to use an expired certificate to sign macros, and will also warn the end user when a digital signature for a file has expired. The end user will see a warning in the usual Digital Signature security warning which indicates the certificate is no longer trustworthy. The user can determine if the certificate is expired by looking in the Details dialog for the certificate.
To prevent you from having to resign your software and VBA projects every time your certificate expires, some commercial certificate authorities provide a timestamping service. If you use a timestamping service when signing code, a hash of your code is sent to a server to record a timestamp for your code. When using a timestamping service, a user’s software can distinguish between code signed with an expired certificate that should not be trusted, and code that was signed with a certificate that was valid at the time the code was signed, but which has subsequently expired.
By default, Office 2000 does not use a timestamping service when signing or validating code. Using a timestamping service usually takes more time than the default digital signing process. To use a timestamping service, Office needs to communicate with a certificate authority’s timestamp server over the Internet to complete the action. You can not timestamp a digital signature unless you are connected to the Internet.
There is no built-in Office UI to use this option. To have Office use a timestamping service with all future digital signatures, you need to set these registry keys.
HKEY_Current_User\Software\Microsoft\VBA\Security\TimeStampURL
HKEY_Current_User\Software\Microsoft\VBA\Security\TimeStampRetryCount
HKEY_Current_User\Software\Microsoft\VBA\Security\TimeStampRetryDelay
For example, if you have a Verisign digital certificate, one TimeStampURL that works is http://timestamp.verisign.com/scripts/timstamp.dll
TimeStampRetryCount is a DWORD registry key value that is the number of retries VBE will attempt to connect to the timestamping server.
TimeStampRetryDelay is a DWORD registry key value that is the number of seconds VBE will delay before retrying a connection to the timestamping server.
When Office 97 opens a document that contains a VBA project signed with Office 2000, there will only be the usual Office 97 security warning. Office 97 does not know how to read the digital signature. However, the user may modify the document and resave without losing the digital signature.
To prevent the user from inadvertently invalidating the signature, Office 97 will not allow you to edit the signed VBA project. You must use Office 2000 to edit the signed VBA project.
If a user chooses to install Office 2000 without Internet Explorer 5, and uses Internet Explorer 3.0 (no Netscape Navigator installed), Office can not digitally sign a VBA project. The necessary Authenticode technology would not be installed. Moreover, when this user resaves a file with signed macros, the digital signature will be lost.
If the user installed Office 2000 on a machine with Netscape Navigator, Internet Explorer 4.0, Internet Explorer 5, Windows 98 or Windows NT4 SP3 or later, then the digital signature would not be lost, and would be safely saved if the VBA project was not changed.
Office 2000 will allow anti-virus scanners to check every document before it is opened by Word, Excel or PowerPoint. It allows the user to feel secure that a file does not contain a known virus. Please refer to http://OfficeUpdate.Microsoft.Com for the anti-virus scanners that support this feature. These anti-virus scanners register their support of this api when they are set up. Office 2000 indicates the number of scanners that are installed at the bottom of the Tools/Macro/Security dialog.
If you update the virus scanner regularly, you may feel sufficiently safe to run under Low security level for these applications and hence avoid all Office Security warnings. It is important that you update the virus scanner often. In the past, new macro virus strains have appeared daily.
Also, you should check to be sure that your 3rd party scanner can at least detect common Trojan horse attacks. Some virus scanners do not attempt to cover such malicious code attacks.
If you move to Low Security, please realize that you are not protected from new viruses or Trojan horses that the 3rd party scanner cannot identify. If you want to secure yourself from new malicious code, you must use Medium or High Security. When you get a non-signed macro security warning, you will know that your virus scanner has not found any known virus in it, and you can make a judgment about the safety of enabling the macro based on the file source and your need to run the macro.
Each person in your organization who shares Office files, needs to be aware of the dangers of enabling macros from an unknown source. If you see a security warning that doesn’t say who wrote the macros, we recommend that choose Disable Macros. If you see a security warning that says it isn’t sure about the person who wrote the macros because it can’t authenticate the certificate, then you need to decide if you really need these macros. If you don’t, then we recommend that you choose Disable Macros. If you really want to run these signed but unauthenticated macros, then make a judgment on the name of the source. If the name of the source is a company and the certificate wasn’t authenticated, you should be very suspicious that there is malicious code in the macros. If the name is your co-worker or friend, and you think they are at least as diligent about disabling suspicious macros as you are, then it is probably safe to Enable those macros, and even add your co-worker to your Trusted Sources list.
If you write your own macros, you should get a certificate and always sign your macros. You can put your certificate in the Trusted list, and avoid all security warnings about your macros.
It’s worth mentioning here, that you may find a number of users who can’t get their old macros running in Office 2000. If your macros in a document aren’t running and they used to in Word 97, it’s probably because the macros are not digitally signed. Word 2000 by default runs in High security and will automatically protect you from unsigned macros. If you know these are your macros, or are safe, you can sign them (follow the instructions in this white paper or in the Help file).
Turn On Macro Virus Protection http://premium.officeupdate.microsoft.com/officeupdate/focus/Articles/O97McroD.htm -- this document does not cover Office 2000 features.
Excel 97 Call Function Patch http://www.officeupdate.microsoft.com/downloadDetails/xl97cfp.htm -- The fix in this patch is already in all shipping versions of Excel 2000.
This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document is subject to change without notice. The entire risk of the use or the results of the use of this document remains with the user. The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
If you use Windows NT4 SP4 (or a newer version of Windows NT), see the Microsoft Security Configuration Manager for Windows NT 4.0 white paper on: http://www.microsoft.com/security/resources/whitepapers.asp?id==42&Parent=6 The Security Configuration Manager is the most comprehensive means to manage access on a computer, it is probably the best way to administer your users and restrict write access to HKEY_LOCAL_MACHINE registry sections.
If you use Windows NT4 SP3, here is a summary of steps necessary to force the end user to use the specified Office security settings.
1. Install Office 2000 while logged in as an administrator.
2. After installation is complete, log in as an administrator.
3. Run “Regedt32.exe.”
4. Activate the HKEY_LOCAL_MACHINE on Local Machine window.
5. Select the HKEY_LOCAL_MACHINE registry section in that window.
6. Select the appropriate registry key section to which you want to restrict access.
7. On the Security menu, choose the Permissions command.
8. Check the Replace permission on Existing Subkeys checkbox.
9. Select Everyone and choose Read for Type of Access.
10. Select all other users and set their Type of Access as appropriate. System and local Administrators group should be kept on Full Control.
11. Click OK.
12. Repeat steps 6 to 11 for each registry section that you want to control.
13. Log off as Administrator and log in as a user without Administrator rights.
14. Test your applications to be sure they work completely under this restricted environment.
This Regedt32.exe utility is discussed in the Windows NT Workstation Resource Kit, Chapter 24: Registry Editors and Registry Administration. You should also consider protecting the registry database files with NTFS security to prevent attacks on the registry security.
You can feel secure that no one can imitate the signature of a person, unless that person was careless about his security. Eventually, as everyone starts to use the Office 2000 security features as recommended above, you won’t get those “annoying” security warnings. The legitimate macros will run without an alert. Unexpected and unsigned macros or viruses will be silently disabled if you are running on High security. While on Medium security, they will trigger a security warning that you should be very concerned about. Just disable macros and get your work done.
This is a preliminary document and may be changed substantially prior to final commercial release. This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document is subject to change without notice. The entire risk of the use or the results of the use of this document remains with the user. The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Unpublished work. 1999 Microsoft Corporation. All rights reserved.
Microsoft, ActiveX, Authenticode, FrontPage, LOBject, Outlook, PhotoDraw, PowerPoint, Visual Basic, Windows and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March 12, 2019
