20 August 2021

Egde Changes How URLs are Copy-and-Pasted

Edge changes how URLs are Copied and Pasted, by taking the page's title to overly the actual link as the visible clickable text. 

Reliability failure

How this works in practice, depends on the target application into which the link is Pasted.  You may see the actual URL there, as you'd have expected, or the page title as plain text, or (as Edge intended) the page title as clickable text that launches the actual URL if clicked.

What happens when these new links are Copied and Pasted back into Edge (or elsewhere) may be a second point of failure, or at least breaking the principle of "least surprise".  Instead of navigating to the actual URL, you may see search results based on the visible text, if considered invalid as a URL.

Exploitability

HTML is inherently exploitable, in that arbitrary visible text can "spoof" the hidden underlying URL.  This is especially true when the visible text appears to be a valid URL, leading the user to expect this is the actual URL that will be reached when clicking the link.  HTML typically applies a blue color and  underlines visible characters to indicate a clickable link, but neither of these visible cues apply to whitespace, allowing unexpectedly large click-risk surfaces, spoofing users who click such space to merely select that window or pane.

The new handling of links by Edge adds opportunities to spoof users, given that Edge is trusting web pages to set how the hidden URL will be presented to the user.  When this visible text is valid as a URL. it will automate launching that URL when pasted back into a web browser, which can in turn hide the nature of the exploit.  For example, the text "http : / / microsoft.com" over actual URL "http : / / google.com" will correctly launch Microsoft's site when pasted back into a web browser that processes the visible text, but launch the Google site when pasted into a web browser that processes the hidden URL.  Try this: http://microsoft.com

HTML risks had already escalated to include hidden autorunning JavaScript and ActiveX, when Windows 98 fell in love with the web, to use HTML everywhere as "rich text"; local folders, active desktop, .chm Help files, Outlook Express and Outlook email "message text", etc.  Today's "HTML" not only relies on JavaScript, but can install PWA (Progressive Web Apps) that can silently run underfoot when the web browser appears to have been "closed".

How to turn off the new feature

You may want to turn off the new feature, as part of risk management, and several sites give advice how to do this, including via Regedit.  This site is especially useful for managing all sorts of settings via Group Policy for sysadmin overlords, or Regedit for the rest of us on Windows Home.

Screen grab of Edge, Settings, "Share Copy Paste"


So far I haven't seen a Regedit for the extra switch within the visible Edge, Settings, "Share, Copy and Paste" UI, i.e. "Use the format selected above when copying links from within web pages".  The text that follows is helpful to tease out what this means; as I understand it, it's links you copy from the page rather than the URL address bar of the browser - and points to the common "grope-ahead" risk scenario, i.e. where software takes risk on behalf of the user, that the user did not indicate an intention to take.

Grope-ahead risks

For example, if you set the shell to open items with a single click (as would happen in a web page), then it's far harder for a user to select a known-malware file to delete it, when the system jumps ahead and "opens" the file (thus running the malware) just because the user selected it.

The above example exploits by-design vulnerability, and such vulnerabilities take notoriously long to be fixed, if ever they are - e.g. years of auto-running hidden macros in "documents", since Microsoft called the Concept PoC a "prank macro" rather than "virus", and initially responded by offering a clean-up tool written specifically for Concept, as if there would never be other macro vir.. uh, "prank macros".  

Grope-ahead risks grow when you consider exploits of code defects; consider the shell's "Preview" pane, indexers, integrated filters that kick in when simply listing files in a folder, etc.  The OS behaves like a crawling infant, putting whatever it finds in its mouth to see what they taste like; too bad if it's the wrong end of a loose power cord!  This breaks the rule: Do not trust arbitrary content, especially from "the edge".

7 August 2021

SSD Seen as Hard Drive in Windows 10

SSDs may still be seen and treated as hard drives, even in the latest Windows 10, if within a USB housing combined with interface-restricted (e.g. USB 2.0) speed.

This echoes the old difficulties with SSDs in Windows 7, which we hoped were history.  I discovered this unexpected issue when attaching a SATA SSD within USB enclosure via a USB 2.0 powered hub, and suspect two factors are at work; USB blocking SATA storage identification, and the constrained speed causing the WEI engine to report the storage as "too slow to be an SSD".  

The result; right-clicking the drive and going Tools, Optimize shows Defrag rather than Optimize for the drive letters on the externally-connected SSD.

You could use this issue to deliberately Defrag an SSD, as may be required to solve an NTFS problem, where there are too many fragmented cluster chains to hold as NTFS Extents.  Hopefully this would be before NTFS has already blindly painted itself into a corner, from which ChkDsk fails to "fix".