{"id":5080,"date":"2023-09-11T19:15:26","date_gmt":"2023-09-11T19:15:26","guid":{"rendered":"http:\/\/cad4security.org\/?page_id=5080"},"modified":"2023-09-26T16:38:48","modified_gmt":"2023-09-26T16:38:48","slug":"soc-vulnerability-4","status":"publish","type":"page","link":"http:\/\/cad4security.org\/index.php\/riscv-vulnerability-details\/soc-vulnerability-4\/","title":{"rendered":"SoC Vulnerability #4"},"content":{"rendered":"
\n
\n\n
\n

The domain of Attacks<\/h3>\n\n\n\n

Software
Hardware<\/p>\n\n\n\n

<\/div><\/div>\n\n\n\n\n\n
\n

Attack Model<\/h3>\n\n\n\n

CAPEC-233: Privilege Escalation\u00a0<\/p>\n<\/div><\/div>\n\n\n\n<\/div>\n\n

\n\n

CWE-ID: – 1272<\/strong><\/h2>\n\n\n\n

Hardware-based isolation and access control (e.g., identity, policy, locking control) of sensitive shared hardware resources such as registers and fuses, and information leakage.   <\/p>\n\n<\/div>\n<\/div><\/div>\n\n\n

\n\n\n\n

Threat Model – Privilege Escalation <\/h3>\n\n\n\n\n
Soc Vul. #<\/th>Name of Core<\/th>Security Requirement<\/th>Threat model description<\/th>Effect<\/th>SW attack model<\/th><\/tr><\/thead>
4<\/td>CVA6 RISC-V CPU<\/strong> <\/td>The privilege level should not be changed during a complete instruction execution<\/td>Privilege Escalation:<\/strong> <\/strong>Privilege level switched to lower privilege levels during the execution of an instruction<\/td>Changing the privilege level during an instruction can update the micro-architectural state to control and data registers (CSR)\u202f <\/td> Software in the guest OS can alter the privilege level during an instruction.\u202f\u202f 
Possible attacks:<\/strong> Access control, Illegal interrupt, information leakage etc\u202f<\/td><\/tr><\/tbody><\/table>
Table 1. Attack model description <\/figcaption><\/figure>\n\n\n\n
\n

Description<\/h3>\n\n\n\n

In a system-on-chip (SoC), the software will commonly access the peripherals through a memory-mapped register interface. Thus, the software can access only certain registers with respect to their privilege level hardcoded in the design. However, through the accessible register interface, malicious software could tamper with the hardware data. During the execution of an instruction, the privilege level should not be altered. Changing the privilege level during this can lead to access control violations and possible integrity loss.\u00a0\u00a0<\/p>\n<\/div><\/div>\n\n\n\n\n\n\n

\n\n\n\n

Security Property<\/h3>\n\n\n\n\n
property priv_viol;  
  @(posedge clk_i)  disable iff (!rst_ni)  ( ariane.csr_regfile_i.privilege_violation) |-> (~ariane.csr_regfile_i.csr_we  && ~ariane.csr_regfile_i.csr_read ); <\/td><\/tr><\/tbody><\/table>
Table 2. Assertions\/properties to check privilege escalation in RISC-V design.<\/figcaption><\/figure>\n\n\n
\n
\n\n

Procedure<\/h3>\n\n\n\n
    \n
  1. Invoke Cadence JG inside the cva6_master folder<\/li>\n\n\n\n
  2. Run the prove_t1.tcl script to check the assertion.\u202f <\/li>\n\n\n\n
  3. Violation in the assertion will generate CEX.\u202f\u202f <\/li>\n<\/ol>\n\n\n\n
    \n
    download files<\/a><\/div>\n<\/div>\n\n<\/div>\n\n
    \n\n
    \n

    Impact of Vulnerability<\/h3>\n\n\n\n

    Loss of confidentiality and integrity of the SoC<\/p>\n\n\n\n

    <\/div><\/div>\n\n\n\n\n\n
    \n

    Severity<\/h3>\n\n\n\n

    TBA (Metrics to evaluate the vulnerability impact)<\/p>\n\n\n\n

    <\/div><\/div>\n\n\n\n\n\n
    \n

    tools used<\/h3>\n\n\n\n

    Cadence JasperGold<\/p>\n<\/div><\/div>\n\n\n\n<\/div>\n<\/div><\/div>\n\n

    <\/path><\/svg><\/div>\n\n
    <\/path><\/svg><\/div>\n\n\n
    <\/div>\n\n\n\n

    Results (counter-example)<\/h3>\n\n\n\n\n

    Fig.1 shows that the property (ref. Table.2) violates the RISC-V design, indicating the read\/write state change (privilege violation) in the generated CEX (shown in Fig.2).  <\/p>\n\n\n\n","protected":false},"excerpt":{"rendered":"

    CWE-ID: – 1272
    \nHardware-based isolation and access control (e.g., identity, policy, locking control) of sensitive shared hardware resources such as registers and fuses, and information leakage.\u00a0\u00a0\u00a0<\/p>\n","protected":false},"author":10,"featured_media":3528,"parent":4639,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_acf_changed":false,"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"acf":[],"_links":{"self":[{"href":"http:\/\/cad4security.org\/index.php\/wp-json\/wp\/v2\/pages\/5080"}],"collection":[{"href":"http:\/\/cad4security.org\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/cad4security.org\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/cad4security.org\/index.php\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"http:\/\/cad4security.org\/index.php\/wp-json\/wp\/v2\/comments?post=5080"}],"version-history":[{"count":9,"href":"http:\/\/cad4security.org\/index.php\/wp-json\/wp\/v2\/pages\/5080\/revisions"}],"predecessor-version":[{"id":5260,"href":"http:\/\/cad4security.org\/index.php\/wp-json\/wp\/v2\/pages\/5080\/revisions\/5260"}],"up":[{"embeddable":true,"href":"http:\/\/cad4security.org\/index.php\/wp-json\/wp\/v2\/pages\/4639"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/cad4security.org\/index.php\/wp-json\/wp\/v2\/media\/3528"}],"wp:attachment":[{"href":"http:\/\/cad4security.org\/index.php\/wp-json\/wp\/v2\/media?parent=5080"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}