bios chronomancy: fixing the core root of trust for ... · | 3 | motivation ! why should you care...
TRANSCRIPT
© 2013 The MITRE Corporation. All rights reserved.. Approved for public release 13-2534
J o h n B u t t e r w o r t h C o r e y K a l l e n b e r g X e n o K o v a h
BIOS Chronomancy: Fixing the Core Root of Trust for Measurement
| 2 |
Introduction
§ Who we are: – Trusted Computing researchers at The MITRE Corporation
§ What MITRE is: – A not-for-profit company that runs six US Government "Federally
Funded Research & Development Centers" (FFRDCs) dedicated to working in the public interest
– The first .org, !(.mil | .gov | .com | .edu | .net), on the ARPANET – Manager for a number of standards such as CVE, CWE, OVAL,
CAPEC, STIX, TAXI, etc
| 3 |
Motivation
§ Why should you care about BIOS security? – It's the first code that runs on your CPU – Almost no one is integrity checking the BIOS, so it's a great place for
multi-year backdoors to reside – BIOS overwrite leads to very annoying/time-consuming to recover
from bricking of machines (CIH Virus) – It's rarified knowledge, so it's cool :)
§ We cared because we wanted to know how trusted computing BIOS security mechanisms work. – What is actually measured to generate Trusted Platform Module
(TPM)-stored BIOS measurements? – Can an attacker defeat these measurements? – How can we build a better root of trust – one that detects an attacker
at the same privilege level as the defender? § Heresy!? Read-on!
| 4 |
Outline
§ How an attacker could get into BIOS § How the trusted computing technology of the Core Root of Trust
for Measurement (CRTM) is rooted in the writable BIOS, and therefore vulnerable to manipulation
§ BIOS malware (tick, flea) that can subvert TPM-mediated trust § Our defensive strategy – BIOS Chronomancy § Conclusions
Rick Martinez – BIOS Security Architect Dell End User Computing Solutions
Dell Intro
* Platform launch August 2008 * Legacy BIOS – x86 assembly language * TCG implementation for Vista Bitlocker * Last generation of legacy BIOS on Latitude
New BIOS available on support.dell.com (A34)
Dell Latitude E6400
Dell Latitude Timeline
2007 2008 2009 2010 2011 2012 2013
2011Latitude E6420
2007Latitude D630
2012Latitude E6430
2012Microsoft Windows 8 (Secure Boot)
2010Latitude E6410
Black Hat USA
2011 -‐ 2012NIST Rollout
2007Microsoft Vista (Bitlocker)
2011NIST 800-‐147 Draft
UEFI Transition2008 -‐ 2009
2008Latitude E6400
| 8 |
Getting into BIOS
§ Access Controls – There are registers that can prevent writes to the BIOS flash* – Signed firmware updates
§ Latitude E6400 BIOS revisions: – A29 did not protect the flash from direct writes to the firmware flash
from privileged applications § A30 and higher do
– A29 did not provide an option to require signed updates § A30 and higher have the option, on newer Dell systems it's required
§ However, even access controls can fail or be bypassed: – In 2009 ITL showed that firmware signing can be bypassed in their
"Attacking Intel BIOS" presentation[1] § Until now, the only BIOS talk to bypass signed update with an exploit
*A detailed discussion about these architectural controls is beyond the scope of this presentation
| 9 |
Dell E6400 BIOS Update
1. Firmware update binary (“HDR”) is copied to kernel memory – Default method is to packetize the HDR file into “rbu packets” – HDR contains more than just the BIOS update (Keyboard
Controller, Management Engine, too) 2. A bit in CMOS byte 0x78 is flipped 3. The system is rebooted 4. BIOS sees CMOS bit is flipped and triggers an SMI to execute
the SMM BIOS Update routine
| 10 |
BIOS Update Routine (1 of 2)
$RPK… Packet=1, size=0x400
Copyright 2011 Dell Inc.. A29
$RPK… Packet=N, size=0x100
EB 39 00 00 00 FF FF FF FF …
$RPK… Packet=2, size=0x1000
00 00 FF FF FF FF FF…
OS Kernel Driver
• The Opera)ng System packe)zes the new BIOS image across the address space. Each packet has a 33 byte rbu_packet header that describes the contents and order of the BIOS image informa)on the packet contains.
• A bit is then flipped in CMOS to indicate to the BIOS upon the next reboot that an update is pending.
| 11 |
BIOS Update Routine (2 of 2)
$RPK… Packet=N, size=0x100
EB 39 00 00 00 FF FF FF FF FF …
$RPK… Packet=N-‐1, size=0x1000
00 00 FF FF FF FF FF… • Upon reboot, the System Management Mode update rou)ne scans for the individual rbu packets and uses them to reconstruct the complete BIOS image.
• SMM then verifies the reconstructed BIOS image is signed by Dell before wri)ng to the flash chip.
System Management Mode RAM SMM Update Rou)ne
Copyright 2011 Dell Inc. A29.. FF FF FF FF FF FF FF FF FF FF
… …
EB 39 00 00 FF FF FF FF FF FF
| 12 |
Attacker Objective and Plan
§ Reflash BIOS chip with arbitrary image despite signed BIOS enforcement.
§ Method: find a memory corruption vulnerability in the parsing of the BIOS update information (RBU packets). This will allow us to seize control of SMM and reflash the BIOS chip at will.
§ The memory corruption vulnerability must occur before the signature on the bios update image is checked.
§ SMM parses the 33 byte rbu_packet header that describes metadata about the BIOS update image. This parsing occurs before the signature check.
| 13 |
Attack Surface
http://linux.dell.com/libsmbios/main/RbuLowLevel_8h-source.html
| 14 |
Packet Parsing
§ SMM first locates the RBU packet by scanning for an ASCII signature upon page aligned boundaries.
§ Once located, members of the RBU packet are stored in an SMM data area for use in later calculations…
| 15 |
Curious GEOR?
§ When reconstructing the BIOS image from the rbu packets, SMM writes an initialization string “GEOR” to the destination memory space where the BIOS image is being reconstructed….
| 16 |
RBU Packet Copied
§ Eventually the portion of the BIOS image described by the RBU packet is copied to the reconstruction location in memory.
§ Notice the size parameter (ecx) for the inline memcpy (rep movsd) is derived from attacker data (g_pktSizeMinusHdrSize).
| 17 |
RBU Packet Parsing Vulnerability
§ In fact, the copy destination and copy source are also both derived from attacker data read in from the current rbu_packet.
§ This is an exploitable buffer overflow.
| 18 |
Lack of Mitigations
§ System Management Mode is missing all of the traditional exploit mitigations you would expect to find in modern applications.
§ No ASLR, NX, stack canaries, and so on…. § This means we can pursue any target with our overwrite, such
as the return address for the rbu packet copying function…
| 19 |
Exploiting the Vulnerability
§ There are actually a number of constraints on the RBU packet data that make exploiting this buffer overflow tricky.
| 20 |
Constraints Overview
§ Our copy destination must point to an area pre-initialized with the “GEOR” string.
§ Copy_dest must be lower in memory than the return address. § We can’t overwrite too much lest we die in the inline memcpy and
never return. § Copy source must be positioned such that attacker controlled
data in the address space ends up overwriting the saved return address.
§ Others….
| 21 |
More Problems
§ The source, destination and size operands are all derived from the same rbu_packet members.
§ Changing one operand, changes the others. § All of the constraints previously mentioned must be satisfied. § Exploitation of this vulnerability can be modeled as a constraints
solving problem.
| 22 |
Constraints Corollary
§ An initialization routine populates the “GEOR” string at the expected copy dest location under “normal” circumstances.
§ We skip this normal initialization routine by setting rbu_packet.totPkts to 1 (which as you can see from the above code, sets totalDataSize=0). If we don’t, the large memset and GEOR writing operation performed by the initialization routine are problematic.
§ This means the expected “GEOR” string won’t naturally occur in the address space, and we will have to inject it somehow to satisfy the *copy_dest = “GEOR” constraint.
| 23 |
Faux GEOR
§ The vulnerable memcpy will only execute if the copy destination points to a location containing this GEOR string.
§ We use a Windows kernel driver that performs memory mapped i/o to write the GEOR string as high up in memory as possible, to allow us to force copy_dest to be within striking distance of the return address we want to overwrite.
§ Like the BIOS update process, we are abusing the fact RAM remains intact during a soft reboot so the GEOR strings we wrote will remain in the address space.
| 24 |
RBU Packet Solution
§ With all those constraints in mind, we brute force an rbu_packet configuration that allows us to pass the sanity checks and overwrite the return address gracefully.
| 25 |
Malicious BIOS Update
$RPK.. Packet=0x83f9, size=0xfffe Shellcode Shellcode
… Shellcode
• The unusually large packet size and packet sequence number cause the packet reconstruc)on area to overflow into SMRAM.
• This allows us to overwrite a return address inside of SMRAM and gain control of EIP while in the context of the BIOS update rou)ne.
System Management Mode RAM SMM Update Rou)ne
Packet Reconstruc)on Space Shellcode Shellcode Shellcode
….
| 26 |
PoC Demonstration Video http://youtu.be/V_ea21CrOPM
| 27 |
Vulnerability Conclusion
§ The vulnerability allows an attacker to take control of the BIOS update process and reflash the BIOS with an arbitrary image despite the presence of signed bios enforcement.
§ Because BIOS is charged with instantiating System Management Mode (SMM), control of the BIOS implies complete control of SMM.
§ Once the attacker has complete control of BIOS and SMM, really Bad Things can start to happen…
| 28 | How can we detect attackers in the BIOS? Trusted Computing Group (TCG) Static Root of Trust for Measurement (SRTM) § In the PC Client Specification[2], the TCG lays out a strategy for
obtaining measurements of critical boot-time components – This should detect things like MBR-based bootkits, or even BIOS
attackers § The SRTM is a chain of trust which is built up at boot time from
the BIOS measuring itself, and measuring every other bit of executable code before control is passed to that code – Measurements stored in TPM, discussed shortly
§ All these measurements are typically gained "for free" when the BIOS is configured to enable the TPM
| 29 |
Terminology
§ Trusted Platform Module (TPM) – Supports secure key generation and secure key storage. – Can “seal” keys or data such that they can only be decrypted if the
PCR set hasn’t changed. – Can act as a root of trust for reporting by signing a quote of its
current PCR set. § Platform Configuration Register (PCR)
– Store 20 byte hashes representing measurements of the system. – Are reset to 0x0020 upon reboot. – Can only be modified with an “Extend” operation. – Extend_PCR0(data): PCR0new = SHA1(PCR0old || SHA1(data))
| 30 |
Example Measured Boot ("measured boot" != UEFI "secure boot")
BIOS code on flash chip Core Root of Trust for Measurement
(CRTM)
BIOS configuration in non-volatile RAM ("nvram"/"CMOS")
Measure 1
Master Boot Record
Partition Table
Mea
sure
5
Mea
sure
4
Peripheral's option/expansion
ROMs code
Config
Peripheral's option/expansion
ROMs code
Config
Peripheral's option/expansion
ROMs code
Config
Measure 0
Trusted Platform Module (TPM)
Ext
end
PC
R0
Ext
end
PC
R1
Ext
end
PC
R2
Ext
end
PC
R3
Ext
end
PC
R4
Measure 3
Ext
end
PC
R5
…
This collection of measurements going forward is the Static Root of Trust for Measurement (SRTM)
| 31 |
All roots of trust are not created equal
Base diagram from http://www.intel.com/content/dam/doc/white-paper/uefi-pi-tcg-firmware-white-paper.pdf
Tarnovsky attack
Our attack
PCRs
| 32 |
Q45 Express Chipset
SPI Flash
System RAM
BIOS Region Begin
0 4GB
www.intel.com/.../datasheet/io-controller-hub-9-datasheet.pdf
| 33 |
Typical E6400 boot sequence 1
Boot Block
SPI Flash
System RAM
Configuration
Modules …
FFFF_FFF0
SMRAM
0 4GB
BIOS Region Begin
| 34 |
Typical E6400 boot sequence 2
Boot Block
SPI Flash
System RAM
…
hashing
TCG Measure (CRTM)
SMRAM
0 4GB
PCR0=SHA1(020 | hash)
| 35 |
General Problems with PCR Hashes
§ Opaqueness – No golden set of PCRs is provided by the OEM. – No description of what is actually being measured and
incorporated into the PCR values.1
– Homogeneous systems can have different PCR values.2 – Duplicate PCR values are unexpected if they're measuring
different data…
1. The TCG specification gives vague guidelines on what should be incorporated into individual PCR values, and many decisions are left to the vendor.
2. Based on our own observation of PCR values across various systems.
■ Example E6400 PCR Set
| 36 |
E6400 PCR0 (CRTM) Measurement
§ PCR0 should contain a measurement of the CRTM and other parts of the BIOS.
§ In the above diagram, the dark areas represent what the E6400 actually incorporates into the PCR0 measurement.
§ Only 0xA90 of the total 0x1A0000 bytes (.15%) in the BIOS range are incorporated, including: – The first 64 bytes of the 42 modules. – Two 8 byte slices at 0xDF4513C0 and 0xDF4513C7. – The CRTM is not incorporated at all.
*BIOS Base is located at FFE6_0000
| 37 |
Implications of the weak SRTM
§ Measurements for things like PCI option ROMs and BIOS configuration are not actually captured.
§ We can modify the majority of the E6400 BIOS without changing any of the PCR values. – Yuriy Bulygin presented a similar discovery at CanSecWest 2013
regarding his ASUS P8P67[3], but did not investigate the details of what information was being measured into what PCRs
§ What if we want to modify any part of the BIOS under the assumption that the entire BIOS is being measured? § Like the splash-screen or the code that instantiates SMM?
| 38 |
Forging the PCRs
§ We can arbitrarily modify any part of the BIOS while still maintaining the expected PCR set if we do the following:
1. Record the expected hashes that the CRTM calculates and
forwards to the TPM for the PCR_Extend operation(s). 2. Modify the BIOS to prevent the legitimate CRTM from being
called. 3. Insert your own CRTM which simply replays the aforementioned
“expected” hashes to the TPM.
§ This method maintains a valid PCR set even if the CRTM incorporates the entire BIOS into the measurement.
| 39 |
Really Bad Things: Firmware Rootkits
§ Created two proof of concept firmware rootkits. § Each is installed programmatically; no hardware modification
required.
1. Tick – Persistent stealth malware – Called the Tick because it “embeds” itself in the firmware – Evades detection by forging PCRs – Once in place, can modify any other portion of the BIOS and inject
itself into SMRAM.
2. Flea – Same stealth/persistence capabilities as the Tick – Able to persist even beyond BIOS updates § “jumps” from one revision to the next
| 40 |
Normal BIOS PCR0 Measurement
SPI Flash
System RAM
BIOS
SH
A1(self)
0xf005b411…
PCR0=SHA1(020 | 0xf005b411…)
0 4GB
| 41 |
PCR0 Measurement with a Tick
SPI Flash
System RAM
BIOS
SH
A1(self)
PCR0=SHA1(020 | 0xf005b411…)
0 4GB
| 42 |
Tick Demo Video http://www.youtube.com/watch?v=S0lRcm3jvFo
The Tick from http://th04.deviantart.net/fs6/PRE/i/2005/087/1/b/The_Tick_by_emucoupons.png
| 43 |
The Flea
§ All the same stealth capabilities of the Tick § Achieves persistence beyond BIOS re-flashes
– “Jumps” from one BIOS revision to another
| 44 |
BIOS Firmware Update
BIOS Firmware Update
The Flea
SPI Flash
System RAM
BIOS
BIOS update?
Clone!! Flash!
0 4GB
| 45 |
Flea Demo Video http://www.youtube.com/watch?v=fvQjhqzxHR8
The Flea – Robert Hooke – Micrographia - 1665 ;)
| 46 | Countermeasure: Timing-Based Attestation "BIOS Chronomancy" § The fundamental premise:
– "Build your software so that if its code is modified, it runs slower." § We coined "timing-based" because it is a superset of the
"software-based" techniques, but using hardware (e.g. TPM) for timing measurement
§ Meant to replace CRTM, but not reimplement entire SRTM § Assumptions:
– Attacker has complete control of execution environment before self-checking begins (i.e. same privilege as defender)
– Self-checking code is time-optimal for a given microarchitecture – There are no free execution slots where an attacker can insert a
"free" instruction and suffer no timing slowdown § There is a decade of work in this area, we can't do the many
many nuances justice. A timeline of related work here: – bit.ly/11xEmlV (timeglider.com link)
| 47 |
§ Read your own data – Incorporated into checksum so if it changes the checksum
changes § Read your own data pointer and instruction pointer
– Indicates where in memory the code itself is reading and executing § Nonce/PseudoRandom Number(PRN)
– Prevent trivial replay, decrease likelihood of precomputation due to storage constraints
§ Do all the above in millions of loop iterations – So that ideally an instruction or two worth of conditional checks per
loop iteration leads to millions of extra instructions in the overall runtime
Components of All Self-Checks
| 48 |
Simplified Selfcheck()
Selfcheck(checksum, nonce, codeStart, codeEnd, codeSize) { while (iteration < 2500000) { checksum[0] += nonce; checksum[1] ^= DP; checksum[2] += *DP; checksum[4] ^= EIP; mix(checksum); nonce += (nonce*nonce) | 5; DP = codeStart + (nonce % codeSize); iteration++; }
}
| 49 |
Simplified Selfcheck() Forgery
Selfcheck_forge(checksum, nonce, codeStart, codeEnd, codeSize) { while (iteration < 2500000) { checksum[0] += nonce; checksum[1] ^= DP; if (DP == myHookLocation) checksum[2] += copyOfGoodBytes; else checksum[2] += *DP; checksum[2] += *DP; checksum[4] ^= EIP; mix(checksum); nonce += (nonce*nonce) | 5; DP = codeStart + (nonce % codeSize); iteration++; }
}
| 50 | TPM-Timing Based Implementation (BIOS Boot-Time) Server Client
Self-‐Check (nonce = signature)
Signed Tickstamp 1 & 2
Self-‐Checksum
TPM
Request Tickstamp(hardcoded)
Signed Tickstamp 1
Request Tickstamp(Self-‐Checksum)
Signed Tickstamp 2
Time
Δt
BOOT
Separate agent requests stored measurement, and sends to server for verifica)on
| 51 |
16700
16800
16900
17000
17100
17200
17300
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39
TPM
Tic
ks
Measurement Instance
18 E6400s with customized BIOS Chronomancy firmware 625k self-check iterations
Without attacker With attacker
| 52 |
21000
21200
21400
21600
21800
22000
22200
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39
TPM
Tic
ks
Measurement Instance
18 E6400s with customized BIOS Chronomancy firmware 1.25M self-check iterations
Without attacker
With attacker
| 53 |
29500
30000
30500
31000
31500
32000
32500
33000
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39
TPM
Tic
ks
Measurement Instance
18 E6400s with customized BIOS Chronomancy firmware 2.5M self-check iterations
Without attacker
With attacker
| 54 |
SPI Flash
System RAM
BIOS
Is BC perfect? NOPE! TOCTOU attackers are ongoing work Enter the "flash hopper" :P
Self-check Done
Gbe LAN
0 4GB
| 55 |
§ Assume attackers can get in § Bad things happen when attackers get in § Trusted Computing implementations should not be trusted
implicitly, they should only be trusted if they are open for independent review (and someone has actually reviewed them ;) – It's ironic that they're overwhelmingly closed source & proprietary.
(Even academics don't usually post their code for open review!1) § As long as the CRTM is implemented in writable firmware, ticks
and fleas will mean that you can't trust any of your SRTM. – And as ITL has shown, a TXT-based Dynamic RTM can depend, in
a security-critical way, on the BIOS/SRTM-generated info [5][6][7] – If you're not going to be using BC, you better be using super
simple true ROM CRTM code
Conclusion
1 Our code for our self-check is at http://code.google.com/p/timing-attestation
| 56 |
But wait…there's just One More Thing!
§ We have released Copernicus ("Question your assumptions!"), a tool to check for basic BIOS/SMM security vulnerabilities – http://www.mitre.org/work/cybersecurity/blog/
cyber_tools_butterworth1.html – Checks configuration bits to see if the BIOS/SMM is writable, ala
Yuriy's talks[3][4] § Dumps BIOS image to allow diffing & analysis
– Can detect Rakshasa, last year's "undetectable" BIOS malware[7] ;)
§ Government organizations: – Talk to us about running this in your environment (pushable via HBSS
- but the data goes to a different server, not ePO) § Commercial security vendors:
– Contact us to incorporate Copernicus's capabilities into your kernel/hypervisor agents. We want maximum availability of this capability. MITRE is a not-for-profit company that only works for the government in the public interest.
| 57 |
Questions?
§ jbutterworth, ckallenberg, xkovah @ mitre.org
§ To learn more about TPMs, Reverse Engineering, and other deep security stuff, check out
§ http://OpenSecurityTraining.info/Training.html – John will be creating BIOS/UEFI classes this coming year, follow
@OpenSecTraining to keep up with news – And if you already know the stuff, take the materials and teach it!
§ Also Corey released OpenTPM so you too can play around with and learn more about the TPM
§ http://code.google.com/p/opentpm/
| 58 |
References § [1] Attacking Intel BIOS – Alexander Tereshkin & Rafal Wojtczuk – Jul. 2009
http://invisiblethingslab.com/resources/bh09usa/Attacking%20Intel%20BIOS.pdf § [2] TPM PC Client Specification - Feb. 2013
http://www.trustedcomputinggroup.org/developers/pc_client/specifications/ § [3] Evil Maid Just Got Angrier: Why Full-Disk Encryption With TPM is Insecure
on Many Systems – Yuriy Bulygin – Mar. 2013 http://cansecwest.com/slides/2013/Evil%20Maid%20Just%20Got%20Angrier.pdf
§ [4] A Tale of One Software Bypass of Windows 8 Secure Boot – Yuriy Bulygin – Jul. 2013 http://blackhat.com/us-13/briefings.html#Bulygin
§ [5] Attacking Intel Trusted Execution Technology - Rafal Wojtczuk and Joanna Rutkowska – Feb. 2009http://invisiblethingslab.com/resources/bh09dc/Attacking%20Intel%20TXT%20-%20paper.pdf
§ [6] Another Way to Circumvent Intel® Trusted Execution Technology - Rafal Wojtczuk, Joanna Rutkowska, and Alexander Tereshkin – Dec. 2009http://invisiblethingslab.com/resources/misc09/Another%20TXT%20Attack.pdf
§ [7] Exploring new lands on Intel CPUs (SINIT code execution hijacking) - Rafal Wojtczuk and Joanna Rutkowska – Dec. 2011http://www.invisiblethingslab.com/resources/2011/Attacking_Intel_TXT_via_SINIT_hijacking.pdf
§ [7] Meet 'Rakshasa,' The Malware Infection Designed To Be Undetectable And Incurable - http://www.forbes.com/sites/andygreenberg/2012/07/26/meet-rakshasa-the-malware-infection-designed-to-be-undetectable-and-incurable/
| 59 |
Backup slides
| 60 |
E6400 PCR[1-3]
§ PCRs 1-3 should contain configuration and option rom measurements.
§ Interesting because they are duplicate values. § We had also seen this a89fb8f… value on other (non-E6400)
systems. § PCR[1..3] = SHA1(0x0020 || SHA1(0x00))
| 61 |
Future Work: Combat TOCTOU
Attacker moves out of the way, just in time
| 62 |
Conditions for TOCTOU
§ 1) The attacker must know when the measurement is about to start.
§ 2) The attacker must have some un-measured location to hide in for the duration of the measurement.
§ 3) The attacker must be able to reinstall as soon as possible after the measurement has finished.
§ It turns out a bunch of the example attacks in the literature are TOCTTOU without being explicit about it.
§ And it turns out TOCTOU more severely undercuts the technique than prior work had recognized
| 63 |
BIOS Acquisition
§ Method 1: Obtain the BIOS ROM from manufacturer
§ Dependent on manufacturer – May not provide straight-forward method to obtain the actual ROM
image – Dell, for example, no longer provides this handy feature.
| 64 |
BIOS Acquisition
§ Method 2: Read it from the BIOS chip using software
§ Write your own if you want to learn the architecture very well
§ Time consuming (but fun and educational)
§ Linux app with iopl() also works well, better for testing
| 65 |
BIOS Acquisition
§ Method 3: Read it from the BIOS chip using hardware
§ Turned out to actually be a requirement … § Not necessarily easy to get at the BIOS chip
| 66 |
BIOS Analysis: Arium CPU Debugger FTW!*
*Some [dis]assembly required.
| 67 |
BIOS Modification: Access Controls 2
BIOSWE can “always” be set to make the flash chip writeable (R/W attributes!)
BLE, however provides SMRAM the final say as to whether or not writes to the flash will be permitted.
E6400 version A29 didn't set BLE, A30 did