Security Reflection
Security TODO: Pre-Meetup Questions from CSE 291
Q: Can you think of some drawback of enforcing security mechanisms at the hypervisor level (compared to at the guest OS or above)? A:
- Limited visibility. The hypervisor operates at a lower level; some context is lost. Some security policies rely on detailed knowledge of the applications and services.
- Limited flexibility and Compatibility. It limits flexibility and may not be compatible with diverse operating systems. It would be a high-level opinion security model and may not fit a highly refined or tailored security policy. The security model at the hypervisor level is a big commitment. It will introduce compatibility issues with existing or future guest operating systems
- Performace overhead: comprehensive security control at the hypervisor level will add complexity and overhead.
Q: When a zone and/or an instance type are used more frequently (i.e., having higher loads from more tenants), do you think the co-location attack would be come easier or harder? Why? A: It will be much easier.
- “multi-tenancy” allows multiplexing the resource as they are the same type or zone. . A new VM has a higher chance of being hosted on the physical server that already hosts another tenant’s VM.
- als of the strong placement locality. “Sequential placement locality exists when two instances run sequentially (the first terminated before launching the second) are often assigned to the same machine. Parallel placement locality exists when two instances run (from distinct accounts) at roughly the same time and are often assigned to the same machine.”
Q: Do you think a similar co-location attack exists with serverless computing (i.e., one function attacking another function on the same physical machine)? Does serverless computing make such attacks harder or easier and why? A: it would be much harder.
- the cloud providers own serverless API. it would be much easier to limit the attack surface and implement security control.
- serverless is Ephemeral, stateless. It is much harder to shoot a moving target.
- serverless on-demand resources mean it is smaller and more flexible in scheduling, making it difficult for an attacker to predict the target’s placement. 4 . serverless normally has another layer isolation, such as a container or vm firecracker.
Note: “When Virtual is Harder than Real: Security Challenges in Virtual Machine Based Computing Environments”
list security challenges inherent in virtual machine-based computing environments. . Scaling: 起VM太方便管不过来 transience, VM是短暂的,很难定位打补丁 software lifecycle, VM的lifecycle是tree-like, 如何roll-back? diversity, VM导致实际跑的OS版本五花八门 mobility, VM是可以snapshot, copy and moved。导致config维护困难,而且有可能整个备份被偷 identity, 没有MAC了,不好identify虚拟环境,而且track their origin and modification history. data lifetime VMM回滚会把已删的信息恢复。paging, checkpointing, and migration 可能泄露重要信息
then propose add virtual machine monitor with centralized security control. Delegating Management 集中方便管理 Guest OS Independence OS可以随意用,因为virtualization layer带了security Lifecycle Independence: 不用在担心rollback导致的一系列问题 Securely Supporting Diversity: A virtual infrastructure should allow users to use old unpatched VMs with diverse OSes much as they would be able to use old or non-standard files without having to change them(?)
“Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds” How to map the physical location of a target VM in cloud infrastructure, then enable cross-VM side-channel attacks.
Security threat in public cloud computing? External attack against infrastructure provider spying on users. cross-user attacks The primary reason is
Placement vulnerability:
-
Cloud cartography: map the internal infrastructure of the cloud to locate the target
-
check for co-residence: network-based co-residence check/covert channel check (unintentional leakage of information), Cache-based cross-VM load measurement on EC2
-
achieving co-residence “Brute-forcing” co-residence Parallel placement locality
-
location-based attacks: So what if VMM provides good isolation?
Cross-VM side-channel attacks: Prime+Trigger+Probe: Spectre, Meltdown Degradation-of-Service attacks Escape from VM.
Solution? Random IP assignment isolates each user view of internal address space (VPC) hide Dom0 from traceroutes. (identify the machine) opt out of multitenancy (dedicated instance) HW/SW countermeasure to stop leakage Improved performance isolation
Other Security Concerns: Cloud service provider being the attacker (insider job)
Confidential Computing: untrust the service provider’s secure enclave that encrypts data whenever it leaves the HW. Partition all HW into a safe world and an unsafe world.