MSRC Blog

This depends what you mean by "security bulletins". In general, Microsoft did stop publishing from their traditional, hand written format a while back.

The closest you get this is sort of thing now, which is completely automated and frequently wrong, and assumes you know what CVE you were searching for.

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36434

One of the bigger vulnerabilities in recent times was Printnightmare, where they did write ups like this due to visibility. I don't feel it actually says much.

https://msrc.microsoft.com/blog/2021/08/point-and-print-default-behavior-change/

There were a lot of Twitter threads about the shitstorm that I can no longer find back when all their bulletins changed formats, but the general reason was moving their "good" bulletins behind an E5 license. Which again, I know some people consider "professional".

So to actually answer your question, here's a screenshot from a paywalled security bulletin. You can see from the scrollbar I'm near the top, and the "Recommendations" are all Defender features (with "apply patch" almost a hidden detail). The statement about configuring AMSI is not a Sharepoint recommendation, it's a Windows security feature originally tied into Defender.

https://ibb.co/WV1HN3q

And everything from here on in this security bulletin on to Sharepoint vulnerabilities - of which very little useful technical information is presented - is about Defender.

Of course, not just the EDR, the first…

That doesn't excuse downplaying the security issues so common when using languages that do not offer memory safety.

Microsoft:

>we’ll peek at why we think that Rust represents the best alternative to C and C++ currently available.

First, there are plenty of fantastic memory safe languages already available and widely used inside and outside of Microsoft, including .NET languages like C# or F# and other languages like Swift, Go, and Python. We encourage anyone who is currently using C or C++ to consider whether one of these languages would be appropriate to use instead.

We, however, are talking about the need for a safe systems programming language (i.e., a language that can build systems other software runs on, like OS kernels). Such workloads need the speed and predictable performance that C, C++, and Rust provide.

When thinking about why Rust is a good alternative, it’s good to think about what we can’t afford to give up by switching from C or C++ — namely performance and control. Rust, just like C and C++ has a minimal and optional “runtime”. Rust’s standard library depends on libc for platforms that support it just like C and C++, but the standard library is also optional so running on platforms without an operating system is also possible.

Rust, just like C and C++, also gives the programmer fine-grained control on when and how much memory is allocated allowing the programmer to have a very good idea of exactly how the program will perform every time it is run.…

TL;DR:

Some Windows configuration have bad permissions on their SAM database.
If a standard user has access to shadow copies (VSS), this can lead to privilege escalation.

Microsoft recommends to [1]:

1) Restrict access to the contents of %windir%\system32\config:
- Command Prompt (Run as administrator): icacls %windir%\system32\config*.* /inheritance:e
- Windows PowerShell (Run as administrator): icacls $env:windir\system32\config*.* /inheritance:e

2) Delete Volume Shadow Copy Service (VSS) shadow copies:
- Delete any System Restore points and Shadow volumes that existed prior to restricting access to %windir%\system32\config.
- Create a new System Restore point (if desired).

--

Also, please note that some authorities seem to adress this subject carefully. The French national cybersecurity agency (ANSSI) has for instance published a News bulletin [2] but no "real" Security bulletin of this vulnerability [3].

In its News bulletin, the ANSSI specifies that it also affects Windows Vista RTM :).

However, the ANSSI also says that deleting VSS entries (step 2 of Microsoft recommendations) "must be decided after evaluating the advantages and disadvantages with regard to the risks, in particular because there may be other possibilities for privilege escalation depending on the level of security of your information system."

[1] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36934

[2] https://www.cert.ssi.gouv.fr/actualite/CERTFR-2021-ACT-031/

[3]…

Probabilistic Arm MTE memory safety is a stepping stone to deterministic CHERI hardware, https://saaramar.github.io/memory_safety_blogpost_2022/ & https://news.ycombinator.com/item?id=39668053

The right kind of mitigations targets the 1st order primitive; the root cause of the bug. Hardware solutions: CHERI (Morello, CheriIoT), MTE Software mitigations: kalloc_type+dataPAC, AUTOSLAB, Firebloom, GuardedMemcpy, CastGuard, attack surface reduction Safe programming languages: Rust, Swift MTE/CHERI play pretty nicely - they help ensure that whatever bugs we have in these areas are killed at their root cause… MSR, MSRC and Azure Silicon pushed for… scaling CHERI down to RISC-V32E, the smallest core RISC-V specification. Microsoft Research open-sourced a hardware/software stack for CHERI in IoT devices, https://msrc.microsoft.com/blog/2023/02/first-steps-in-cheriot-security-research/

CHERI-based microcontroller that aims to… get very strong security guarantees if we are willing to co-design the instruction set architecture (ISA), the application binary interface (ABI), isolation model, and the core parts of the software stack… our microcontroller achieves the following security properties: Deterministic mitigation for spatial safety (using CHERI-ISA capabilities). Deterministic mitigation for heap and cross-compartment stack temporal safety (using a load barrier, zeroing, revocation, and a one-bit information flow control scheme). Fine-grained…

Those who think C is inherently good can’t be convinced otherwise. Any argument will be dismissed with “programmers need do be better”. Any assertion will be dismissed as subjective, lacking data. Any data backed study from Microsoft [1] or Google [2], [3] will be dismissed as Big Tech hiring mediocre programmers. There will be vague references to “just use the right sanitizers”.

Ultimately we need to recognise that for some people, language is a core part of their identity. At that point criticising “their” language hurts them. If we’re talking to someone who feels this way, it’s best to politely say “is that so?” and gently disengage.

I know it’s tempting to think that we could show them just one compelling data point that will change their minds. But that’s not any more possible than convincing someone to stop believing in religion by pointing out factual inconsistencies in scripture. If you tell a committed Christian that Jesus couldn’t have been born in 0AD because Herod died in 4BC and the census they were travelling for happened in 7AD … is that going to make them reconsider everything about their religion? No, they’ll dismiss this as a minor issue that can be worked around. Same with $language programmers.

1 - https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/

2 - https://www.chromium.org/Home/chromium-security/memory-safety/

3 - https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html

MSRC (Microsoft Security Response Center) — https://msrc.microsoft.com/

They’ll close a report as “no action” if the issue isn’t related to Microsoft products. That said, in my experience they’ve been a reasonable intermediary for a few incidents I’ve reported involving government websites, especially where Microsoft software was part of the stack in some way.

For example, I’ve reported issues in multiple countries where national ID numbers are sequential. Private companies like insurers, pension funds, and banks use those IDs to look up records, but some of them didn’t verify that the JSON Web Token (JWT) used for the session actually belonged to the person whose national ID was being queried. In practice, that meant an attacker could enumerate IDs and access other citizens’ financial and personal data.

Reporting something like that directly to a government agency can be intimidating, so I reported it to Microsoft instead, since these organizations often use Azure AD B2C for customer authentication. The vulnerability itself wasn’t in Microsoft’s products, but MSRC’s reactive engineers still took ownership of triage and helped route it to the right contacts in those agencies through their existing partnerships.