Friday, August 7, 2015

BHUSA15: Black Hat Roundup

I just got back from my first Black Hat conference!  This may seem strange, that I've never been, but it always  seemed to expensive and many of the talks were repeated at DefCon.  My first DefCon was DC2 - I was still basically a kid. I could not drink nor gamble, but I had a blast year after year meeting super bright folks and learning neat hacks.  Learning what I did at DefCon has definitely shaped my career - there's no way I would've ended up in a more than two decades long career in computer security without it.

Did DC have it's down sides? Yes, definitely. As noted by a woman on the "Beyond the Gender Gap" panel, it gets tiring "proving it again" (and again) every time I would walk into the room at DefCon. "Who's your boyfriend?" "I'm single" "Or, so you're a scene whore?" "No" "Oh, then you're a fed!"

Then I would have to proceed to prove my technical prowess over and over again. (best advice for men came from that panel: never start with "who are you here with?", but rather "What do you do?") [Note: I did have a boyfriend my first couple of DefCons, and later a husband - who did not come, as he wasn't interested in the con, but I was at other times single.]

DefCon also had amazing moments - here we are at DC9 in 2001. Babies!  (I don't seem to have older pictures on my site - but I was there, usually with Artimage and Angus).

But, that didn't happen at Black Hat. Folks (men and women) spoke to me like a human. It was really nice.  Other than when I went to the bar to meet one of my friends Tuesday night, nobody started at my chest. I was able to attend two women focused luncheons and meet lots of interesting and smart security focused women.  Black Hat USA has a Code of Conduct, lots of staff, and plenty of time between sessions to network, charge batteries or go pee.

I want to thank Runa Sandvick who first of all gave an awesome talk on a wifi rifle (you know, we all need one) and gave me the free pass to attend!

Still surprising to see people drinking at 7:30 in the morning, and drinking EVERYWHERE (in the elevator a lot).  Coming from California, all the smoking was strange, too. A guy sat next to me in a session "vaping" pot - really? Can't wait until break?  Fortunately, the conference halls were non-smoking, so I escaped an asthma attack.

Overall, a very informative conference! I would highly recommend, for the very high caliber, true research talks.

Did you have a good time? Any stories to share?

Thursday, August 6, 2015

BHUSA15: Hi This Is Urgent Plz Fix ASAP: Critical Vulnerabilites and Bug Bounty Programs

Kymberlee Price, Bugcrowd.(aka @kym_possible)

We won't be talking about low level bug bounty programs today, just the critical bugs. Kyberlee has extensive background as a developer and has been working lately on a "red team".

Google does a vulnerability reward program (VRP) that they produce some data one. It doesn't include the Chrome award, Android award, or patch award program - but it includes logs of other things! Google.com, google play, etc.  

The more time that passes, the fewer vulnerability reports that come in - but seems to be higher quality. Google has had to increase their bounty to keep the bugs coming in.

Facebook has a similar program and had 17,000 submissions in 2014 alone. Out of that, onlyl 61 high severity bugs. Their minimum award is $500.  Their total payout for valid submissions wwas $1.3 million to 321 researchers. Their top 5 researchers made a total of $256,750 - those had to be massive vulnerabilities.

India is Facebook's highest valid bug submissions, with Egypt coming in second - and USA in third place.  In India, the average payout was $1343, in Egypt $1220 and US $2470.

Github's bug bounty program is 1 year old today!

Microsoft will pay up to $100,000 for novel exploitation techniques against protections built into the OS, and an additional reward of up to $100,000 if you also develop a defense.

MS runs a "hall of fame" - which indicates you received a bounty. If your vuln results in a CVE, you'll be noted in the security alert.

Depending on whether it software or online services will change who is submitting your bugs (like India is very high for MS's online services, but not as many for software.

Followed 166  customer bug bounty programs, there were 37,227. There wer about eight thousand non-duplicate, valid vulnerabilities. Of those 3, 621 were awarded - paying out $700,00+ (average payout around $200, largest $10,000).

Every one of these programs is getting really critical vulnerabilities.

Who is finding these?  Professional Pen Testers and consultants (in their spare time), former developers, QA engineers and IT admins.

India, US and Pakistan are top three for volume of submissions.

Reginaldo Silva reported an XML external entity vulnerability within a PhP page tha would have allowed a hacker to change Facebook's use of Gmail as an OpenID provider to a hacker-controlled URL, before servicing requests with malicious XML codes. Fixed quickly and the developer was rewarded and recognized.

Kymberlee then did a deep dive into a few of these fun (and very serious) vulnerabilities found, even including videos and audio from the researchers who found these themselves. These vulnerabilities were things like banks and cars!

You need to make sure you tell researchers in advance what you need to help you triage it faster (this can be email or webform). Set expectations, but you need to have a rapid triage and prioritization process in place (to get to the P1s faster).

Now, don't expect an eloquent write up - English may not be their first language. Allow them to provide a video of the reproduction steps.

You need to have  your "in scope" and "out of scope" clearly defined, and a process for how to handle things that don't fit into either category (because they weren't defined well enough - it will happen).

To reduce noise, provide pointers to guidance and training, like Bugcrowd's forum.

Have a plan to deal with duplicates. Don't see this often for P1 or P2, because those are fixed quickly.  Don't let the lower priority bugs languish, either. If they are getting reported over and over again, you're wasting resources telling the researchers they have hit a duplicate - and if researchers are finding this every week, so are the bad guys.

 Some of the bugs can be so severe that they are worth the entire program. You don't want those vulnerabilities out there.

How to reduce noise? Publish and stick to your program SLA. Stop rewarding bad behavior (ie don't give someone "hall of fame" acknowledgement just because they are pestering you).  Don't create bad behaviour by being consistent, rewarding quickly, having good documentation.

By crowdsourcing this, you can bring people from around the world into your security team - people who cannot or do not attend conferences like Black Hat, etc.

This was a really fascinating and informative presentation!

BHUSA15: When IoT Attacks: Hacking a Linux-Powered Rifle

Runa A. Sandvik is a privacy and security researcher, working at the intersection of technology, law and policy.

 Michael Auger is an experienced IT security specialist with extensive experience in integrating and leveraging IT security tools.

Runa and Mike spent the last year researching the Trackingpoint 338TP. When CNN asked Runa why attack a rifle? She replied, because "cars are boring".

The base rifle is Remington 700 .308 bolt-action rifle. Hardware platorm is called "cascade, runs modified Angstrom Linux.

It uses Tag Track Xact (TTX) .

The wifi is off by default, and you cannot fire the rifle remotely.  The gun still works even if the scope/targeting system is broken - it is a gun, after all.

The first thing that they did was run a port scan on the rifle. It runs a webserver and rtsp server.

The more interesting side is the TrackingPont App - you can adjust settings for wind, media, and do software updates.

The mobile app was using encryption, etc.

 When they got stuck ... they just tried ALL THE THINGS! :-)

After round 1, found that the SSI contains the serial number, and it can't be changed. Guessable WPA2 key, and it also cannot be changed. Any RTSP client can stream the scope vie.

The API is unauthenticated, but it does validate input.

There is a 4 digit pin that locks advanced mode - you can brute-force. /set_factory_defualts" resets the lock.  Updates to the rifle are GPG encrypted and signed.

 Round Two...

Fortunately Tracking Point's website has an excellent diagram of what the rifle would look like, before tearing it a part. They actually used their CAD drawings in their marketing material.  Though, the website has a lot of 2D things, in reality the circuit board is round :-)

To get the circuit board out, you have to desolder at least 60-pins.

So excited to see it booting Linux!

But, alas, it did not auto-login as root.

Console access is at least password protected and the kernels and filesystem are on separate chips.

the filesystem chip was hidden under a big capacitor - missed it the first few times.

Some of the folks they were working with recognized the silk screening on the board and recommended an EMC to USB converter. Then got to see what was on the filesystem.

The webserver had a lot of interesting APIS, like ssh_accept - that could be fun!

The system backend requires unpublished API call to open port. The API validates input, backend does not. You can make temporary changes to the system. Can change wind, temperature, ballistics valus and control the solenoid, etc.  They could even lock the trigger, crash the gun, make the scope think it is attached to a different firearm, or make this one command segfault (which triggers reboot).

The changes are temporary, if the user reboots, the changes will be lost.

Now time for demos!

Watched a change in the ballistics screw up the calculation so that the shot hit the target next to the one you were aiming at.

TrackingPoint operates with two GPG keys for updates, one of which is on the scope. Update script accepts packages signed by either of the two keys. This will allow you to make persistent changes to the system AND get root access.

Successfully able to login with no password as root!

Round 3 findings: the Admin API is also unauthenticated, the system backend is unauthenticated and does not validate input. GPG key on the scope can encrpt and sign updates.

Did have to have previous access to the rifle for all of the attacks.

But, there are ways to do remote code execution - if you can get on the wifi.

it's not all that bad... USB ports are disabled during boot, media is deleted from scope once downloaded, SPQ2 is in use, even if key cannot be changed. The API does validate user input, console access is password protected and software updates are GPG encrypted and signed.

Will this get better?  Have been calling them since April, zero replies, until Wired called... since have received two calls. TrackingPoint is working on a patch. They have been easy to work with, once the connection was made.

"You can continue to use WiFi (to download photos or connect to ShotView) if you are confident no hackers are within 100 feet" - note on TrackingPoint's website. :-)

They had done security work (better than most people doing embedded work).

BHUSA15: Black Hat Panel – Beyond the Gender Gap: Empowering Women in Security

Kelly Jackson Higgins, Executive Editor at Dark Reading (panel moderator)

This is a growing industry, but women are leaving. We need more people, so how do we empower the women we have?

Panelists:
Justine Bone, Independent Consultant
Joyce Brocaglia , Founder Alta Associates (executive search firm for security, etc)
Jennifer Imhoff-Dousharm, co-founder, dc408 and Vegas 2.0 hacker groups
Katie Moussouris, Chief Policy Officer, HackerOne

All of the women here come from different backgrounds - hacking (black hat and white), executives, startups, big companies.

Justine learned a big hard lesson when she dropped out of industry to work on her own startup - at the same time as having kids.  While she was working her butt off, she wasn't showcasing her work or engaging with her peers - everybody thought she'd taken off time to have kids, totally unaware of the hard work she'd been doing. Lesson: always engage, promote, etc.

Joyce mentioned that she sees a lot of Employee Research Programs that are more checkboxes than actually beneficial programs for women. She noted that a company might pay Alta  $100-$150,000 to find a new executive, but when she asks if they'll pay $100,000 for leadership program with a proven track record - the same company will say "we don't have that kind of money." (note: sigh)

Katie started up a bug bounty program at MS - it was hard.  Big companies had vowed to never pay ransom for security bugs - she had to present this in a different way, to get it to line up with their goals, getting organizational empathy (when is the best time for devs to get vulns). Hence, IE 11 Beta Bug Bounty - which ran for 30 days. Alas, folks would hold on to their vulns until after beta was closed, forcing MS to release vulnerability reports.

We have a shortage of engineers, why aren't women coming in?  Jennifer said she doesn't see it as a pipeline problem - she noted that women that grew up in the 80s were exposed to computers (yay, Oregon Trail) and didn't hit the "cootie" program until they entered corporate America. It's scary to be the only person like you in the room - you don't realize it until you are that only woman. It doesn't matter how strong you are or how much you lean in, you have to carry that weight of diversity.

Justine noted the "DefCon problem" - it's annoying that everyone asks you "who are you here with? who's your boyfriend" - it gets exhausting. (Note: YES - happened to me every year, after my bf & I broke up and I continued to go alone).  Explaining over and over that you deserve to be there, what you do, that you really are technical.

Katie noted there's a challenge as well that you are expected to be a representative of ALL women, irregardless of how different we all are.  She hates the question: "what's it like being a woman in security?" - stop asking her about the least important aspect of her job and her personality, she is so much more than just "a woman in security."

Joyce notes that she sees job advertisements all the time that will literally use the male gendered pronoun, "he will be responsible for X, Y, Z". Knowing that men will apply for a job where they only meet 6/10 of the qualifications, and women require 9/10 before they will apply.. adding "he" to the description is one thing off the bat that the woman will not be.  Confidence matters as much as competence - men tend to have more confidence, which may help explain why women are not making it to the higher levels.

Companies need to invest in younger women to make these changes - they are an investment.  Women and men need sponsors, but companies should make sure that it's not only men getting them. If women are raising their hands for stretch assignments, but getting skipped over... is it their fault?

Justine noted that we also need to be willing to accept help - if someone tries to bring you into the "old boys club" - GO! Joyce cautioned, though, don't wait for it.

Justine says she's always criticized for her travel for work, by friends, family, etc. How could she leave her kids? She notes she's on these flights with a ton of men doing the same thing - and nobody criticizes them.

Can you have work and family?  Yes, but you need help - nannies, families, etc. "Women have the capacity to multitask and get shit done," Joyce.

Personal space at these events is important. Katie had a run in with "Handsy McMansy" last night - fortunately, she's adept at profanity to throw at him. The men around though seemed shell shocked and didn't know what to do. "I don't need somebody to fight for me, I need them to fight with me."

Joyce had a run in last night that was similar with a male executive, sloppy drunk, asking dumb questions and hanging on people. If a woman did that - she would be shamed by the men around.

Joyce noted that women still don't get taken seriously at booths at events like RSA.  People don't want to talk to the women, even if they may be the one making purchasing decisions.

Justine looked at the Black Hat review board this morning - there is only ONE woman on the review board. Not saying the men on the board are not skilled and talented, but they need diversity.

Joyce noted that women need to submit talks, start with smaller conferences and get practice, confidence, etc. 

Men should talk to women at conferences - acknowledge them, don't question why they are here - but actually engage. Like, "what do you do at your company?" vs "who's your boyfriend?"

Joyce noted that older generations of men are lacking the emotional intelligence to understand why what they are doing or saying is not okay. She has high hopes for the younger generations, who grew up with working mom's, etc.

Katie noted that women need to stop denigrating yourself - the world will do that for your. Speak about your work in positive tones, not "well, I don't do kernel work, I don't do... ". Believe in yourself and don't be afraid to tell the world about what you do.

BHUSA15: Information Access and Information Sharing: Where We Are and Where We Are Going

Alejandro Mayorkas, Deputy Secretary of Homeland Security.

Homeland security means security of our institutions, security of our way of life and most importantly security of our values.  Security of the Internet is very much a part of what we do. It is clear that the challenges of network security are immense. We as a government are making advances in this area, but we are not where we need to be.

Every morning, the secretary and get a briefing about threats, events that are occurring or are about to occur all over the world. Increasingly Internet security events are more common in that meeting.

The more he travels around the country, it becomes obvious how important this is for everyone.  Internationally, the same thing. Foreign companies and governments all care about this.

The current state of affair with individualized responses is not working well to ensure that the Internet is protected.  DHS considers themselves uniquely situated to address these concerns. DHS is a civilian agency, standing at the intersection of Private Sector, Enforcement community, Intelligence Community and desire to protect .gov.  They have created a critical response set of protocols and organization (National Cybersecurity Communications Organization).

DHS currently shares information in bulletins or entity to entity. It is not currently in an automated fashion. The President, in his last executive order, placed DHS in charge of leading information sharing with the private sector.

DHS wants an automated and near real time way to share and disseminate information, to raise the bar and capacity for the private sector to protect themselves.  When a threat is shared with DHS, they can receive that in automated form and disseminate in near real time to prevent replication of that threat.

One thing in their way: the issue of trust. That emanates from a variety  of sources - can DHS keep this secure? can you trust those providing information?

DHS needs to work on building trust - it will take time, but will be worth the effort.

As they are working on the automatic reception of cyber threats, please give them a chance and share some information so that they can prove their capabilities and prove their results.

Question about how important is it for private industry to participate?  Answer: very, many of them are very critical systems. It's critical they participate.

We have to understand our responsibilities for the public good. Alejandro hopes that sharing the cyber threat will have a public dimension. It's vital for them to be shared far more publicly than they are now. This is important for DHS's mission to secure this country.

DHS is very active in research and development in achieving network security - we are investing in public as well as private sector.

Various questions show that folks are nervous about sharing with the government, Alejandro noted that they will be working on correcting that.

Another questioner asked about the OPN breach, where NASA, etc, lost lots of personal information.  He noted that not all agencies are as advanced as others, and they've been doing a 30 day security activity with the goal of improving this.

Question: will information about 0-days that the government has bought be shared? Answer: we are going to declassify and release everything that we can.

Question: gov't is know for antiquated systems, how do we know you'll do this right? Alejandro noted that they have to start with new gear, and stay on top of the systems. (no Windows NT here)

Additionally, DHS is looking at recruiting the best and the brightest, and even looking at opening an office in Silicon Valley.

BHUSA15: Where? You can't Exploit What You Can't Find

Christopher Liebchen & Ahmad-Reza Sadeghi & Andrei Homescu & Stephen Crane

 We're concerned with many problems that are actually 3 decades old. Nowadays, everyone has access to cell phones. Many developers with different intentions and different background (particularly with security).

So - how do we build secure systems from insecure code?  Seems counter-intuitive, but we have to do it. We cannot just keep adding more software onto these old systems.

We've had decades of run-time attacks - like the Morris Worm in 1988, which just keeps going.

There are a number of defenses, but often the "defenses" are broken by the original authors juts a few years ago.  So, there is a quest for practical and secure solutions... 

Big software companies, like Google and Microsoft, are very interested in defending against run-time attacks, like Emet or CF Guard in MS or IFCC and VTV from Google.  But how secure are these solutions?

The Beast in Your Memory: includes bypass of EMET. return oriented programming attacks against modern control-flow integrity protection techniques... 

The main problems are memory corruption and memory leakage.

You can do a code-injection attack or a code-reuse attack.

Randomization can help a lot, but not perfect.

Remember, for return-oriented programmng: basic idea: use small instruction sequences instead of whole functions. Instruction sequences of length 2to5, all sequences end with a return instruction. Instruction sequences chained together, modifying what code is executed after return.

Assuptions for our adversary model: memory pages are writable executable, we also assume there is address space layout randomization (ASLR), and that it can disclose arbitrary readable memroy.

 Main defenses: code randomization and control flow integrity.


Randomization has low performance overhead and scales well to complex software  Though, this suffers with low system entropy and information disclosure is still hard to prevent.

For CFI: formal security (explicit control flow checks) - if something unexpected happens, you can stop execution (in theory).  It's  a trade-off be performance and secuity (inefficient) and chalenigng to integrae in complex software. 

What about fine-grained ASLR? You are just trying to make it more complicated.  But, this has been attacked by JIT-ROP (BH13).  That undermines any fine-grained ASLR and shows memory disclosures are far more damaging than believed. This can be instantiated with real-world exploits.

Then we got a pretty graphical demo of how JIT-RoP works.

Their current research is around code-pointer hiding.

Their objectives were to prevent code reuse & memory disclosure attacks. It should be comprehensive (ahead of time + JIT), practical (real browsers) and fast (less than 6% overhead).

We prevent direct memory disclosures by using execute-only code pages, which prevent direct disclosure of code. Previous implementations do not entirely meet our goals. So, we fully enforce execute-only permissions with current x86 hardware.

We have virtual addresses that get translated to physical addresses. During the translation, the MMU can enforce some translations. As soon as your code page is executable, it is also readable.  But you might want something to be readable, but not executable.  Can do this with extended page tables, which will note that something is only executable (not readable).

The attacker can leak pointers to functions that point to the beginning or in the middle - once he's got that pointer, he can figure a lot more things out.

So, we can add another layer of indirection: code pointer hiding!

They modified the readactor compiler so we would have codedata separation, fine-grained code randomization, and code-pointer hiding.

our goal is to protect applications which are frequent targets of attack. They have JIT (just in time) code, which is harder to protect, as it frequently changes.  Solution: Alternate EPT usage between mutable mapping RW-) and execute-only mapping (--X).

Now, does this actually work?  Checked performance with SPEC CPU2006 and chromium benchmarks. Checked practicality bye compiling and protecting everything in Chromium.

The full readactor caused roughly 6.4% slowdown. But, if you only protect the hypervisor in execute only mode, that's only around 2% performance impact, which seems acceptable.

How does it do wrt security? Resilience against (in)direct memory disclosure.

Code resuse attacks are a a severe threat, everyone acknowledges this. Readactor: first hardware enforced execute-only fine-grained memory randomization for current x86 hardware.












BHUSA15: The Memory Sinkhole – Unleashing an x86 Design Flaw Allowing Universal Privilege Escalation

Chris Domas is an embedded systems engineer and cyber security researcher, focused on innovative approaches to low level hardware and software RE and exploitation.

There has been a bug in x86 architecture for more than 20 years... just waiting for Chris Domus to escalate privileges.

Chris did the demo on a small, cheap netbook computer. In case it didn't work, he had a stack of netbooks.  We saw just running a program where a general user ran a simple program and had root.

Some things are so important that even the hypervisor should not be allowed to execute it.

We originally wanted to do power management without the OS to worry about it - system management mode. SMM becamse a dumping ground for all kinds of things, eventually it took "security" enhancements.  Now SMM is imortant: root of turst, TPM emulation and communication, cryptographic authentication...

Whenever there was something important or sensitive or secret, it got stuck in SMM.

Userland is at Ring 3, kernel in Ring 0 . Ring -1 is they hyperviser... Ring -2 is SMM. On modern systems , Ring 0 is not in control. We have to get deeper (and hide from) Ring 0.

If you're in ring 0 and try to read from SMM - you'll just get a bunch of garbage. Memory control separated SMRAM from the rest of the system. If you're in SMM, though, you can read from SMRAM.

There are many protections on SMM - locks, blocks, etc.  but most exist in the memory controller hub. Lots of research in this area on how to to get to Ring -2.

The local APIC used to be a physically separate chip that did this management. But, it's more efficient and cheaper to put the local APIC on the CPU.  Now it's even faster!

Intel reserved 0xfee0000-0xfee01000 - so to access, you have to do some round about ways to get there. When they created this model, this broke legacy systems that expected that segment of memory to map to something else. Looking at the Intel SDM, c 1997 describes what's happened here in the P6.

Now we're allowed to move where the APIC window is located, allowing us to access APIC reserved space.  This "fix" opens systems up to this vulnerability.

If we're in Ring 0, and we try to read SMRAM we will be denied. But, you can do it from SMM. What if we're in Ring 0, and relocate the APIC window. Now, from Ring 0, we can read SMRAM.  Now that we can do that, we can modify SMM's view of memory.  Now the security enforcer has been removed.

How to attack ring -1 from ring 0? SMRAM acts as a fe haven for SMM code. As long as SMM code stays in SMRAM, ring 0 cannot touch it. But if we can get SMM code to step out of its hiding spot, we can hijack it.

Move APIC over SmRM, corrupt execution , trigger fault in SMM. This gets is to look up an exception handler - under our control.  Though, that attack doesn't work. There's an undocumented security feature which causes a triple fault (reset) the system.

He overlayed APIC MMIO range at the SMI entry point: SMBAE+0x80000 - getting the APIC entry point and the SMBAE to overlap.

Now, we just need to store shell code in the APIC registers. The challenge is they have to be 4 K aligned. Place  exactly SMI entry. Execution begins @ exactly start of APIC registers.4096 bytes available.

Many registers are largely hardwired to 0, giving few registers that can actually be changed. We need to do something useful before the system resets.

You need to keep things from executing right away before our last byte is activated.

we only really have 4bits to do something to actively attack the system.  Looking at the opcode map, not a lot of interesting things.

But, the attack didn't work as expected. We still can't execute from the APIC, so must control the SMM with data alone.

How do we attack code when our only control is to disable some memory?

SMM code comes from system firmware.  Intel makes template code, which goes to independent BIOS vendors, then the OEMs (HP, Toshiba, Lenovo) makes more changes.

The only way to make a general attack is to look at the EFI template BIOS code from Intel, as that will be on EVERY system.

From ring 0, we try to sinkhole the DSC to switch it into system management mode.  We've lsot control, but maybe it'll let us do something before memroy resets.

(lots of stuff about self rewriting code, and far jumps and long jumps and lots of hex codes)

Then we successfully got the SMM to read code that we could control, by controlling the memory mapping.

With only 8 lines of code, to exploit: hardware remapping, descriptor cache configurations, etc.

In the end, used well behaving code in order to abuse a different area.

This has opened up a new class of exploits.  Now that we have Ring -2 control, what can we do?  We can disable the cryptographic checks, or turn off temperagur control, brick the system, or install a root kit.

Once we have the control, we can preempt the hypervisor, periodic interception, filter ring 0 i/o, modify memory, escalate processes, etc.

Adapted code from Dmytro Oleksiuk.

We can simultaneously take over all security controls. Mitigations don't look good. This is unpatchable, would need new processors.... Which Intel did. Their developers seem to have found this independently. This is now fixed with Sandy Bridge and Atom 2013. Now check in SMRRs with APIC is relocated.

intel.com/security has a write up on this. They have been easy to work with, and have been working on mitigations where ever it was architecturally possible.