Why Is The Dollar Sign A Letter S?

The letter S appears nowhere in the word "dollar", yet an S with a line through it ($) is unmistakably the dollar sign. But why an S? Why isn't the dollar sign something like a Đ (like the former South Vietnamese đồng, or the totally-not-a-joke-currency Dogecoin)?

There's a good story behind it, but here's a big hint: the dollar sign isn't a dollar sign.

It's a peso sign.

Bohemian Rhapsody

Though the dollar and peso symbols are inextricably linked, the origin of the word "dollar" is rooted in elsewhere. Its story begins in 1500s Bohemia, a central European kingdom spanning most of today's Czech Republic.

Central Europe had just become rich with silver. After centuries of sending its silver (and gold) abroad in trade for consumable luxuries like silk and spices (very little of which ever found its way back), new sources of silver ore were discovered in Saxony, German Tyrol and Bohemia. With far more silver than still-scarce gold, Tyrol began replacing its teeny-tiny gold coins with big heavy silver coins of equal value. The newly-minted guldengroschen coin, 32g of nearly-pure silver, was an instant hit.

Fast forward to 1519. The Kingdom of Bohemia's Joachimsthal region was finally producing enough silver to begin minting a heavy silver coin of its own. This new Bohemian joachimsthalercoin improved on the guldengroschen, adjusting the weight and purity slightly to make the coin evenly divisible into existing European weights and measures. It rapidly became the new European favorite, and soon most anyone with silver was minting their own version. The -thalersuffix came to refer to any and all of these similar heavy silver coins . . . and over the next few decades the thaler coins came to have several transliterated variations on their names: the Slovenian taler, Dutch daalder, and in English, the word thaler became dollar.

A Whole New World

Central Europe may have been flush with silver by earlier standards, but by the 1530s the mines were already slowing down . . . and all their riches would be utterly eclipsed by what Spain had just found in the New World. Between melting down the silver of conquered civilizations and heavy mining for more, for the next three hundred years 85% of the world's silver production would come from Spanish-controlled Bolivia, Peru, and Mexico.

While other nations had been sporadically reducing the silver content of their once-nearly-purethaler/daalder/dollar coins, Spain suddenly had more silver than any other nation on earth, and therefore no reason to ever debase their country's coinage. And the seemingly unending flow of silver meant they could mint a lot of those coins, too.

Blessed with both quantity and stability, the Spanish real de a ocho coin (commonly known as apeso de ocho or"piece of eight") gradually supplanted all competing thalers as the coin of international trade. Before long, the "Spanish dollar" was being used everywhere from the West Indies to the Far East.

For a feel for just how widespread this single Spanish coin really was, just look at the names of a few national currencies used today:

• Eight countries (Argentina, Chile, Colombia, Cuba, Dominican Republic, Mexico, Philippines, and Uruguay) call their currency the peso,
• China and Japan's respective yuan and yen currencies are named for the round shape of Spanish pieces of eight (on which the first yuan coins were modeled),
• The riyal of Saudi Arabia (and therefore the Saudi-based Qatari riyal as well) got its name from the Spanish real, historically represented in the region by the peso de ocho coin,
• And when it came time for the newly-formed United States of America to create their own currency, they chose to name it the dollar, after the Spanish dollar coin (the most circulated coin in the country at the time, and for a surprising number of years after as well.) This was the first formal use of "dollar" as a base currency instead of a single coin, but the trend caught on, and the dollar is now the base currency of 37 nations and 9 territories.

Yes, so influential was the silver "piece of eight" that 32% of the world's population live in countries with currencies named for, or originally patterned after, that single Spanish coin, including the modern U.S. dollar.

P.S. I Love You

Most of our modern symbols owe their existence to the tediousness of handwriting. Writing things by hand was slow (and boring), so scribes would look for ways to speed (and liven) things up.

As one example, the ampersand (&) began its life as the Latin word "et" (meaning "and") . . . first as a stylized ligature where the two letters were connected, eventually resulting in a single conjoined symbol. The "at symbol" (@) probably got a similar start, although nobody's entirely sure what was originally abbreviated for that one.

As previously noted, the peso de ocho was the go-to currency for international trade. Anyone frequently conducting trade was likely conducting much of it in pesos, and would then be stuck writing the word "pesos" on their ledgers, over and over and over and over. Which would have been boring, and also needlessly wasteful of both time and ink.

So merchants devised a simple and obvious shorthand: "P" for "peso" (when plural, "P^s"). It could have ended there, but some (I assume they were just bored) merchant(s) thought it would be even cooler to write the P and S on top of each other. This apparently caught on, and by the 1770s they had dropped the bowl from the P entirely, reducing the shorthand to an S crossed with the vestigial stem of what once was a P. And thus was born a brand new symbol, still used to mean peso today: the peso sign ($).

And because the US dollar was named after the Spanish peso de ocho "dollar" coin, the same peso symbol was ultimately used to refer to pesos and dollars both.

And that is why the dollar sign is an S with a line through it.

MS15-011 & MS15-014 (JASBUG) Vulnerability

Today we are releasing MS15-011 & MS15-014 which harden group policy and address network access vulnerabilities that can be used to achieve remote code execution (RCE) in domain networks. The MS15-014 update addresses an issue in Group Policy update which can be used to disable client-side global SMB Signing requirements, bypassing an existing security feature built into the product.MS15-011 adds new functionality, hardening network file access to block access to untrusted, attacker controlled shares when Group Policy refreshes on client machines. These two updates are important improvements that will help safeguard your domain network.

What’s the risk, i.e., what’s the attack scenario?

Let’s looks at one of the typical attack scenarios as outlined in the below diagram.

This is an example of a  ‘coffee shop’ attack scenario, where an attacker would attempt to make changes to a shared network switch in a public place and can direct the client traffic an attacker-controlled system.

1. In this scenario, the attacker has observed traffic across the switch and found that a specific machine is attempting to download a file located at the UNC path: \\10.0.0.100\Share\Login.bat .
2. On the attacker machine, a share is set up that exactly matches the UNC path of the file requested by the victim: \\*\Share\Login.bat.
   1. The attacker will have crafted the contents of Login.bat to execute arbitrary, malicious code on the target system. Depending on the service requesting Login.bat, this could be executed as the local user or as the SYSTEM account on the victim’s machine.
3. The attacker then modifies the ARP table in the local switch to ensure that traffic intended for the target server 10.0.0.100 is now routed through to the attacker’s machine.
4. When the victim’s machine next requests the file, the attacker’s machine will return the malicious version of Login.bat.
   This scenario also illustrates that this attack cannot be used broadly across the internet – an attacker need to target a specific system or group of systems that request files with this unique UNC.
   

What were the Group Policy vulnerabilities?

An RCE vulnerability existed in how Group Policy received and applied policy data when connecting to a domain. Concurrently, a vulnerability existed whereby Group Policy could fail to retrieve valid security policy and instead apply a default, potentially less secure, group policy. This could, in turn, be used to disable the domain enforced SMB Signing policy.

What did we fix under MS15-014?

The risk of circumventing SMB Signing was fixed by correcting how Group Policy would behave when it fails to retrieve a current, valid security policy. After applying the fix, Group Policy will no longer fall back to defaults and will instead the last known good policy if a security policy retrieval fails.

What did we harden under MS15-011?

While SMB Signing safeguards against Man-In-The-Middle attacks, with the vulnerabilities like the above in Group Policy it is possible to disable it. But more importantly, SMB Client doesn’t require SMB Signing by default so it is possible to direct the domain related traffic, especially the unencrypted traffic, to attacker controlled machines and serve malicious content to the victims in response. To block this kind of attacks we added the ability to harden the UNC path access within domain network.

Universal Naming Convention (UNC) is a standardized notation that Windows uses to access file resources; in most cases these resource are located on a remote server. UNC allows the system to access files using the standard path format: \\<hostname>\<sharename>\<objectname>, for example, \\contoso.com\fileshare\passwords.txt, without requiring the application or user to understand the underlying transport technology used to provide access to the file. In this way, the UNC client in Windows abstract network file technologies, such as SMB and WebDAV, behind a familiar file path syntax. UNC paths are used in Windows in everything from printers to file shares, providing an attacker a broad surface to explore and attack. To properly address this weakness in UNC, we had to improve UNC to allow a server to authenticate itself to a client, thereby allowing the client machine to trust the content coming from the target system and be protected from malicious file shares.

How did we harden it?

When an application or service attempts to access a file on a UNC path, the Multiple UNC Provider (MUP) is responsible for enumerating all installed UNC Providers and selecting one of them to satisfy all I/O requests for specified the UNC path. On a typical Windows client installation, MUP would try the Server Message Block (SMB) protocol first, but if the SMB UNC Provider is unable to establish an SMB connection to the server, then MUP would try the next UNC Provider and so on until one of them is able to establish a connection (or there are no remaining UNC providers, in which case the request would fail). 

In most scenarios, the security of the server is paramount: the server stores sensitive data, so file transfer protocols are designed in such a way that the server validates the client’s identity and performs appropriate access checks before allowing the client to read from or write to files. The trust boundary when Group Policy applies computer and/or user policies is completely reversed: the sensitive data is the client’s configuration and the remote server has the capability of changing the client’s configuration via transmission of policy files and/or scripts. When Group Policy is retrieving data from the policy server, it important that the client performs security checks to validate the server’s identity and prevent data tampering between the client and the server (in addition to the normal security checks performed by the server to validate the client’s credentials). It is also important that MUP only send requests for Group Policy files to UNC Providers that support these client-side checks, so as to prevent the checks from being bypassed when the SMB UNC provider is unable to establish a connection to the server.

Group Policy isn’t necessarily the only service for which these extra client-side security checks are important. Any application or service that retrieves configuration data from a UNC path, and/or automatically runs programs or scripts located on UNC paths could benefit from these additional security checks. As such, we’ve added new feature, UNC Hardened Access, along with a corresponding Group Policy setting in which MUP can be configured to require additional security properties when accessing configured UNC paths. 

When UNC Hardened Access is configured, MUP starts handling UNC path requests in a slightly different manner: 

Each time MUP receives a request to create or open a file on a UNC path, it evaluates the current UNC Hardened Access Group Policy settings to determine which security properties are required for the requested UNC path. The result of this evaluation is utilized for two purposes: 

1. MUP only considers UNC Providers that have indicated support for all of the required security properties. Any UNC Providers that do not support all of the security properties required via the UNC Hardened Access configuration for the requested UNC path will simply be skipped.
2. Once a UNC Provider is selected by MUP, the required security properties are passed to that UNC Provider via an Extra Create Parameter (ECP). UNC Providers that opt-in to UNC Hardened Access must respect the required security properties indicated in the ECP; if the selected UNC Provider is unable to establish a connection to the server in a manner that satisfies these requirements (e.g. due to lack of server support), then the selected UNC Provider must fail the request.

Even 3^rd party applications and services can take advantage of this new feature without additional code changes; simply add the necessary configuration details in Group Policy. If a UNC Provider is able to establish a connection to the specified server that meets the required security properties, then the application/service will be able to open handles as normal; if not, opening handles would fail, thus preventing insecure access to the remote server.

Please refer to http://support.microsoft.com/kb/3000483 for details on configuring the UNC Hardened Access feature.

Consider the following scenario:

• Contoso maintains an Active Directory domain named corp.contoso.com with two Domain Controllers (DCs) named dc1.corp.contoso.com and dc2.corp.contoso.com.
• A laptop is joined to the aforementioned domain.
• Group Policy is configured to apply a Group Policy Object (GPO) to the laptop that configures UNC Hardened Access for the paths \\*\NETLOGON and \\*\SYSVOL such that all access to these paths require both Mutual Authentication and Integrity.
• Group Policy is configured to apply a GPO to the laptop that runs the script located at \\corp.contoso.com\NETLOGON\logon.cmd each time a user logs on to the machine.

With the above configuration, when a user successfully logs onto the laptop and the laptop has any network access, Group Policy will attempt to run the script located at \\corp.contoso.com\NETLOGON\logon.cmd, but behind the scenes, MUP would only allow the script to be run if the file could be opened and transmitted securely:

1. MUP receives a request to open the file at \\corp.contoso.com\NETLOGON\logon.cmd.
2. MUP notices that the requested path matches \\*\NETLOGON and paths that match \\*\NETLOGON are configured to require both Mutual Authentication and Integrity. UNC Providers that do not support UNC Hardened Access or indicate that they do not support both Mutual Authentication and Integrity are skipped.
3. The Distributed File Server Namespace (DFS-N) client detects that the requested UNC path is a domain DFS-N namespace and begins its process of rewriting the UNC path (all DFS-N requests will be subject to the same security property requirements identified by MUP in step 2):
   1. The DFS-N client uses the DC Locator service and/or DFS-N DC Referral requests (depending on the OS version) to identify the name of a DC on the domain (e.g. dc1.corp.contoso.com).
   2. DFS rewrites the path using the selected DC (e.g. \\corp.contoso.com\NETLOGON\logon.cmd becomes \\dc1.corp.contoso.com\NETLOGON\logon.cmd). Since Mutual Authentication is required and the target is expected to be a DC, DFS utilizes a special Kerberos Service Principal Name (SPN) to verify that the name retrieved in the previous step is indeed the name of a DC (if the name is not a DC, Kerberos authentication would fail due to an unknown SPN)
   3. If there are additional DFS-N links in the specified UNC path, the DFS-N client continues iterating and replacing paths to DFS-N links with paths to available targets until it has a UNC path that does not have any remaining DFS-N links.
4. The final UNC path is passed back to MUP to select a UNC Provider to handle the request. MUP selects the SMB UNC provider since DCs utilize SMB to share the NETLOGON and SYSVOL shares.
5. The SMB UNC Provider establishes an authenticated session with the selected SMB Server (if an authenticated session is not already present). If the authenticated session is not mutually authenticated (e.g. authentication was performed utilizing the NTLM protocol), then SMB UNC Provider would fail the request to open logon.cmd since mutual authentication requirement identified in step 2 could not be met.
6. The SMB UNC Provider enables SMB Signing on all requests related to logon.cmd since MUP informed SMB that integrity is required for this request. Any attempts to tamper with the SMB requests or responses would invalidate the signatures on the requests/responses, thus allowing the receiving end to detect the unauthorized modifications and fail the SMB requests.

In this scenario, the client-side requirement of end-to-end mutual authentication and integrity protects the laptop from running a logon script located on a malicious server via the following security checks:

• The requirement for Mutual Authentication ensures that the connection is not redirected to an unexpected (and potentially malicious) SMB Server when SMB Client attempts to establish a connection to the requested UNC path.
• The requirement for Integrity enables SMB Signing, even if the SMB Client does not require SMB Signing for all paths by default. This protects the system against on-the-wire tampering that can be used to change the contents of the logon.cmd script as it is transmitted between the selected DC and the laptop.
• The combined requirements for both Mutual Authentication and Integrity ensures that the final rewritten path selected by DFS-N Client matches a path allowed by the DFS-N namespace configuration and that spoofing and/or tampering attacks cannot cause DFS-N client to rewrite the requested UNC path to a UNC path hosted by an unexpected (and potentially malicious) server.

Without these client-side protections, ARP, DNS, DFS-N, or SMB requests sent via Group Policy over untrusted networks could potentially cause the Group Policy service to run a the logon.cmd script from the wrong SMB Server.

How do I configure to protect myself/my users?

Once the update included as part of the bulletin MS15-011 is installed, follow the instructions at http://support.microsoft.com/kb/3000483 to ensure your systems are adequately protected.MS15-014 will install and provide protection without any additional configuration.

 

A word on CVD and fixing difficult problems

In many regards, this security ‘fix’ is more accurately described as completely new functionality in Windows. Adding something of this scale posed a unique challenge to security response. Software vulnerabilities are typically more narrowly constrained in both investigation and remediation – and most response is structured to address that scope. Among the benefits of Coordinated Vulnerability Disclosure (CVD) is it provides for greater flexibility and deeper collaboration with researchers to take the necessary time and perspective to deliver the most complete security solutions to customers. In this case we tackled a vulnerability that required a much greater scope in engineering to deliver a solution.

Most vulnerabilities reported to the MSRC are bugs in a single component, which are investigated, understood, and fixed within industry accepted response times. Creating the new functionality of UNC Hardening, however, required an entirely new architecture which increased development time and necessitated extensive testing. Thanks to CVD, and the close collaboration with the passionate security researchers who reported the vulnerability, Microsoft had sufficient time to build the right fix for a complicated issue. If the security researchers were not willing to refrain from disclosure until our fix was ready, customers would have been put at risk.

Microsoft offers its appreciation to the CVD community and a special thanks to the reporters of the issue which has resulted in UNC Hardening: Jeff Schmidt of JAS Global Advisors, Dr. Arnoldo Muller-Molina of simMachines, The Internet Corporation for Assigned Names and Numbers (ICANN) and Luke Jennings from MWR Labs.