Protecting RAM

Attacks on RAM are one of the arguments to better protect data in use.

There are various security attacks on RAM. One is malware that can scrape memory e.g. for plaintext credit card numbers (once read into RAM prior to encryption).  Modern systems aim to encrypt data as early as possible in the processing pipeline.

Privileged operators (e.g. cloud admins) can peek into RAM. This is why confidential VMs isolate memory to hide data-in-use from cloud providers. 

DMA devices such as Thunderbolt peripherals can read system memory (and hence potentially sensitive data, from RAM). Modern operating systems restrict "hot-plug" DMA access.

Note: this list of compromise attacks is non-exhaustive. This is a big field of operations.

WebAssembly Not Automatically Blocked by Browsers

WebAssembly is a type of code designed to run in modern web browsers.  It is designed to run alongside JavaScript using WebAssembly JavaScript APIs - creating an option for performance critical functionality.

As WebAssembly increases the browser's attack surface, so browsers contain WASM inside the browser's sandbox and restricts system access. 

A risk maybe breaking out of the sandbox. Adobe Flash was a product sandboxed after a bunch of exploits, and after sandboxing exploits still occurred.

Transmission of WASM does not require TLS, HSTS or any other transport layer security mechanism making it susceptible to man-in-the-middle attacks.

Integrity checking is also impossible as WASM modules need not be signed by the author.

Some security-focused browser configurations can block WASM.

Risk Managing WSL

If you are manager of desktops and need to understand WSL risks, here is a summary.

WSL allows users root access inside their Linux instance with ability to install a host of useful software including compilers, packages etc. Linux binaries may be run which Windows Defender may not fully inspect.

However, users have no admin rights on Windows itself.

There are a number of risks which include unmonitored code execution and running unvetted network services as well as bringing unmanaged Linux tooling into the Windows estate.

It can be managed, but adds an additional complexity layer.

There is some degree of isolation between WSL and Windows but not completely. File systems are mutually accessible (from WSL, access Windows directories via /mnt/c, for example).

Note that Windows Defender scans WSL files.

The Same Origin Policy (SOP) on Modern Web Browsers

The Same Origin Policy (SOP) is a browser-enforced security rule that prevents scripts from one "origin" (PDP -> protocol + domain + port) from accessing resources from another origin.

The SOP prevents cookies, DOM and local storage from being read by malicious cross-site scripts.

The SOP does not just apply to web browsers. For example, Electron apps (desktop apps built with web tech) enforce SOP because they embed Chromium.

The Same Origin Policy is an "isolation model" designed to ensure "secure workflow".

Technology designed to integrate into browsers (e.g. WebAssembly) generally respect the existing SOP.

Addressing AI Misuse

OpenAI has a Preparedness Framework aimed at addressing AI misuse.

The domain of cybersecurity features prominently here, since AI can be used to enhance security, but equally make it easier to scale up cyberattacks.

Am I up to date with Windows Update? How do I check?

Update History

Type "Windows Update" in the Windows Search Bar and then click on "View your Update history".

Quality versus Feature Updates

There are a wide variety of updates, examples being Feature updates (rare) and Quality updates (common). Quality updates tend to be security fixes. Occasionally you will see Driver Updates as well as Definition updates, that relate to antivirus definitions (Windows Defender).

CVEs

Clicking into specific Quality updates will give details on any CVEs (Common Vulnerabilities and Exposures) which the update is trying to fix.

Remote Desktop Protocol Vulnerability is Patched

A bug in RDP (nicknamed "BlueKeep") allows an unauthenticated attacker to connect to a system using RDP. This would allow arbitrary code execution on a target system.  Microsoft has released a fix for Windows 7 in Patch Tuesday. "Exploit Wednesday" has been an unofficial term for the window of opportunity post patch release when unpatched machines will be exploitable to cyberattack.

A Review of SSL/TLS - Preventing POODLE Attacks (Revealed by Google in 2014)

WJ has talked about this before in the context of IIS but it's always good to revise basic security concepts pertinent to the Windows world. These concepts are becoming increasingly important as programmers are expected to become more cyber-conscious.

SSL is the (now largely legacy) Secure Sockets Layer created in the mid 1990s (the first public version was released in 1995), designed for cryptographically secure data transport (now known not to be so secure). It is technically prohibited by the IETF. The first version was pioneered by Netscape.

TLS is the successor for SSL.

TLS is recommended above SSL due to the POODLE attack (impacting SSLv3) discovered by Google researchers (and publicised October 2014, when SSLv3 was already nearly 18 years old) allowing padding data at the end of the block cipher to be exploited, to iteratively degrade security.  It also exploits the tendency of browsers to fall back on earlier protocols when connections fail.

The follow on recommendation was to advise against use of SSLv3.

The POODLE attack is an abbreviation for "Padding Oracle on Downgraded Legacy Encryption" and is a man-in-the-middle exploit.

Padding oracle attacks are associated with block ciphers, which encrypt information in blocks, and may incorporate "padding bits". The attack relies on the presence of a "padding oracle" that responds to answer whether a cryptographic message is correctly padded or not.

Some random facts on TLS, what it stands for etc.

TLS (Version 1.0) was first defined in January 1999. Tim Dierks is one of the original authors.