{"id":609,"date":"2022-07-20T16:01:56","date_gmt":"2022-07-20T16:01:56","guid":{"rendered":"https:\/\/fde.cat\/index.php\/2022\/07\/20\/using-hermess-quicksort-to-run-doom-a-tale-of-javascript-exploitation\/"},"modified":"2022-07-20T16:01:56","modified_gmt":"2022-07-20T16:01:56","slug":"using-hermess-quicksort-to-run-doom-a-tale-of-javascript-exploitation","status":"publish","type":"post","link":"https:\/\/fde.cat\/index.php\/2022\/07\/20\/using-hermess-quicksort-to-run-doom-a-tale-of-javascript-exploitation\/","title":{"rendered":"Using Hermes\u2019s Quicksort to run Doom: A tale of JavaScript exploitation"},"content":{"rendered":"

At Meta, our Bug Bounty program<\/a> is an important element of our \u201c<\/span>defense-in-depth<\/span><\/a>\u201d approach to security. Our internal product security teams investigate every bug submission to assess its maximum potential impact so that we can always reward external researchers based on both the bug they found and our further internal research assessment of where else the bug could lead us.<\/span><\/p>\n

We want to share more about how this process works. To do this, we\u2019re sharing details of an investigation into a bug report we received in August 2020 concerning <\/span>Hermes<\/span><\/a>, an open source JavaScript (JS) engine developed by Meta. This initial report showed a peculiar bug in Hermes\u2019s<\/span> Quicksort<\/span><\/a> implementation, resulting in blind out-of-bounds (OOB) memory reads.<\/span><\/p>\n

Reports like this help us continue to improve our detection mechanisms in Hermes and across our platform. Similar findings are usually awarded between $500 and $3,000. However, further investigation demonstrated how this vulnerability could have been turned into arbitrary code execution. This resulted in a $12,000 total bounty payout.<\/span><\/p>\n

To make things more fun, and to demonstrate the impact of what we found, we programmed our exploit to run the classic video game <\/span>Doom<\/span> (1993) directly from within Hermes.<\/span><\/p>\n

Hermes, a lightweight JavaScript engine<\/span><\/h2>\n

Hermes<\/span><\/a> is an open source JS engine optimized for<\/span> React Native<\/span><\/a>. It features<\/span> ahead-of-time compilation<\/span><\/a> to reduce startup time and memory usage, making it particularly suitable for mobile applications. At Meta, for example, Hermes is used to run the JS code for effects in<\/span> Spark AR<\/span><\/a>, our augmented reality development platform. In July 2020, we launched the <\/span>Hermes\/Spark AR <\/span><\/a>track to further incentivize security research on Hermes.<\/span><\/p>\n

The bug, sorting the unsortable<\/h2>\n

In August, 2020, we received a report showing a crash in Hermes caused by an<\/span> OOB read<\/span><\/a>. The report featured a tangled JS file of about 180 lines of code, most likely created by a<\/span> fuzzing<\/span><\/a> engine. After some cleanup, we pinpointed the root cause.<\/span><\/p>\n

The crash occurred while executing the<\/span> Array.prototype.sort method<\/span><\/a>, in code related to some recent<\/span> changes<\/span><\/a> to make Hermes\u2019s <\/span>sort<\/span> implementation<\/span> stable<\/span><\/a>. A sorting algorithm is said to be stable if the order of equal elements remains the same after sorting.<\/span><\/p>\n\n

In Hermes, this was achieved by using a separate <\/span>index<\/span> vector<\/span> prefilled<\/span><\/a> with the element\u2019s original indices [1] (see code comments). Whenever two elements in the array are swapped, their indices are<\/span> swapped as well<\/span><\/a> [2]. If two array elements are equal, their original indices\u2019 values<\/span> are compared<\/span><\/a> instead [3]. This guarantees stability.<\/span><\/p>\n

ExecutionStatus quickSort(SortModel *sm, uint32_t begin, uint32_t end) {
\n uint32_t len = end – begin;
\n \/\/ [1]
\n std::vector<uint32_t> index(len); \/\/ Array of original indices of items
\n for (uint32_t i = 0; i < len; ++i) {
\n index[i] = i;
\n }
\n …
\n return doQuickSort(sm, index, \/* … *\/ );
\n}<\/p>\n

…<\/p>\n

ExecutionStatus
\n_swap(SortModel *sm, std::vector<uint32_t> &index, uint32_t i, uint32_t j) {
\n if (sm->swap(i, j) == ExecutionStatus::EXCEPTION) {
\n return ExecutionStatus::EXCEPTION;
\n }
\n \/\/ [2]
\n std::swap(index[i], index[j]);
\n …
\n}<\/p>\n

…<\/p>\n

CallResult<bool>
\n_less(SortModel *sm, std::vector<uint32_t> &index, uint32_t i, uint32_t j) {
\n auto res = sm->compare(i, j);
\n if (res == ExecutionStatus::EXCEPTION) {
\n return ExecutionStatus::EXCEPTION;
\n }
\n \/\/ [3]
\n return (*res != 0) ? (*res < 0) : (index[i] < index[j]);
\n}<\/p>\n

Array.prototype.sort can take, as an argument, a function defining a custom sort order:<\/span><\/p>\n

const array = [3,1,4,2];
\narray.sort(function compareFn(first, second) { … });<\/p>\n

But what happens if we use this callback to modify the array while sorting? When sort<\/span> <\/span>is first called, it will use the initial version of the array, but after executing the comparison function, sort<\/span> <\/span>will see the modified version.<\/span><\/p>\n

On the other hand, index<\/span> <\/span>, whose length reflects the initial array\u2019s size, remains unchanged. As a result, the array and index length might differ. This might happen, for example, if new elements are added to the array from within the callback.<\/span><\/p>\n

In this case, accessing elements beyond the original array\u2019s size during sorting will result in OOB accesses in index.<\/span><\/span><\/p>\n

Understanding the Quicksort algorithm<\/span><\/h3>\n

To understand how to control which elements get accessed, we need to understand the underlying<\/span> Quicksort algorithm<\/span><\/a>.<\/span><\/p>\n

Quicksort starts by selecting a pivot element, picked to be the median of three elements. It then searches for an element larger than pivot (as reported by the callback function) from left to right (<\/span>i<\/span>). Once this larger element is found, the algorithm looks for an element smaller than pivot from right to left (<\/span>j<\/span>). Those elements are then swapped and the procedure is repeated until the two searches \u201ccross each other,\u201d at which point the pivot is swapped with the smaller element (<\/span>j<\/span>).<\/span><\/p>\n\n

Causing an OOB read<\/span><\/h3>\n

Now, let\u2019s put everything together and use the callback to trick the sorting algorithm implementation into sorting elements beyond the original array:<\/span><\/p>\n

We start by extending the array beyond its original size (so to be larger than index<\/span><\/span>).<\/span>
\nWe then wait to get past the <\/span>median-of-three<\/span> step (used to select a pivot), which requires three comparisons.<\/span>
\nAt this point, we keep returning -1 to advance the left index <\/span>i<\/span> until we have reached the target cell past the original array\u2019s size.<\/span>
\nFinally, we return 0, indicating that the two elements are equal. This will cause an OOB read to the index buffer.<\/span><\/p>\n

var array = [1,2,3,4,5,6,7,8,9,10];
\nconst initial_length = array.length
\nconst extended_length = initial_length*2
\nvar cnt = 0<\/p>\n

array.sort(function compareFn(first, second) {<\/p>\n

cnt++;<\/p>\n

\/\/ [1] Extend the array
\n if (cnt == 1){
\n for (i=0; i<extended_length-initial_length; i++){
\n array.push(‘X’)
\n }
\n }<\/p>\n

\/\/ [2] Get past the median-of-three step
\n if (cnt > 3){<\/p>\n

\/\/ i represents the left index moving to the right
\n const i = cnt – 1;<\/p>\n

\/\/ target_cell can be anything between initial_length and extended_length
\n const target_cell = 15;<\/p>\n

if (i != target_cell){
\n \/\/ [3] If we didn’t yet reach the target cell, keep advancing
\n return -1;
\n } else {
\n \/\/ [4] If we did reach the target cell, trigger an OOB index lookup
\n print(“Look for the crash…”)
\n return 0;
\n }
\n }
\n});<\/p>\n

Executing the above code on an<\/span> ASAN<\/span><\/a> build of Hermes produced the following crash:<\/span><\/p>\n

Look for the crash…
\n=================================================================
\n==1519183==ERROR: AddressSanitizer: heap-buffer-overflow …
\nREAD of size 4 at 0x604000003fc8 thread T0
\nSCARINESS: 27 (4-byte-read-heap-buffer-overflow-far-from-bounds)
\n#0 0xcd011a in hermes::vm::_less(…) hermes\/lib\/VM\/JSLib\/Sorting.cpp:35
\n#1 0xccf3de in hermes::vm::quickSortPartition(…) hermes\/lib\/VM\/JSLib\/Sorting.cpp:175
\n#2 0xccf3de in hermes::vm::doQuickSort(…) hermes\/lib\/VM\/JSLib\/Sorting.cpp:262
\n#3 0xccef6e in hermes::vm::quickSort(…) hermes\/lib\/VM\/JSLib\/Sorting.cpp:332
\n#4 0x953f41 in hermes::vm::arrayPrototypeSort(…) hermes\/lib\/VM\/JSLib\/Array.cpp:1248
\n#5 0x8b3ee9 in hermes::vm::NativeFunction::_nativeCall(…) hermes\/include\/hermes\/VM\/Callable.h:539
\n#6 0xa27a2f in hermes::vm::Interpreter::handleCallSlowPath(…) hermes\/lib\/VM\/Interpreter.cpp:318
\n…<\/p>\n

Let the hacking begin<\/span><\/h2>\n

After understanding the root cause of a bug, we immediately work with the relevant product\/feature development team to issue a fix. In the meantime, we always ask ourselves, \u201cHow serious is this?\u201d and work to determine the bug\u2019s maximum potential impact.<\/span><\/p>\n

So, how serious was this Hermes bug? We have seen how it could be used to access elements beyond <\/span>index<\/span>, but could it have been used to obtain something more than a crash?<\/span><\/p>\n

Swapping the unswappable<\/span><\/h3>\n

Quicksort works by swapping elements and, when two elements are swapped, their respective indices are also swapped. Therefore, at least in theory, this bug might be used to swap indices with neighboring elements outside the index vector.<\/span><\/p>\n

If so, we could obtain the ability to do some loosely controlled writes out of the index.<\/span><\/p>\n

There are two types of swaps in Quicksort:<\/span><\/p>\n

Between <\/span>i<\/span> and <\/span>j<\/span>
\nBetween <\/span>j<\/span> and the pivot<\/span><\/p>\n

We decided to look at the first option since the sorting algorithm lets us control both <\/span>i <\/span>and <\/span>j<\/span>:<\/span><\/p>\n

while (true) {
\n \/\/ [1]
\n while (true) {
\n ++i;
\n res = _less(sm, index, i, pivot);
\n if (res == ExecutionStatus::EXCEPTION) {
\n return ExecutionStatus::EXCEPTION;
\n }
\n if (!*res) {
\n break;
\n }
\n }
\n \/\/ [2]
\n while (true) {
\n –j;
\n res = _less(sm, index, pivot, j);
\n if (res == ExecutionStatus::EXCEPTION) {
\n return ExecutionStatus::EXCEPTION;
\n }
\n if (!*res) {
\n break;
\n }
\n }
\n \/\/ [3]
\n if (i >= j) {
\n break;
\n }<\/p>\n

\/\/ [4]
\n if (_swap(sm, index, i, j) == ExecutionStatus::EXCEPTION) {
\n return ExecutionStatus::EXCEPTION;
\n }
\n }<\/p>\n

The swap [4] happens once <\/span>i<\/span> is pointing to an element smaller than pivot [1] and <\/span>j<\/span> is pointing to an element larger than pivot [2].<\/span><\/p>\n

An intermediate check [3] ensures that <\/span>i<\/span> and <\/span>j<\/span> are swapped only if they haven\u2019t crossed each other (<\/span>i.e.<\/span>, <\/span>i < j<\/span> ), but in order to swap elements out of the index, <\/span>i<\/span> and <\/span>j<\/span> must cross.<\/span><\/p>\n

To solve that, we decided to<\/span> underflow<\/span><\/a> j <\/span>(a 32-bit unsigned integer) so that <\/span>j = 0xffffffff<\/span>.<\/span><\/p>\n

In a 32-bit system, <\/span>index[0xffffffff]<\/span> is equivalent to <\/span>index[-1]<\/span>, which corresponds to the element immediately before the index.<\/span><\/p>\n

Unfortunately, reading j = 0xffffffff <\/span><\/span>will cause the application to hang in the loop at [2]. This is because <\/span>array[0xffffffff]<\/span> is \u201cempty,\u201d which, according to the<\/span> specs<\/span><\/a>, is considered to be greater than everything. As a result, the loop searching for an element smaller than the pivot will keep looping until the whole 32-bit address space has been explored.<\/span><\/p>\n

To solve for this we defined a custom getter so that array[0xffffffff]<\/span><\/span>will not return an empty element.<\/span><\/p>\n

Array.prototype.__defineGetter__(0xffffffff, …);<\/p>\n

At this point, we were able to swap index[j]<\/span><\/span> and index[i]<\/span><\/span>, where j = 0xffffffff<\/span><\/span>. Notice that we can also arbitrarily decrement <\/span>j<\/span> and\/or increment <\/span>i<\/span>,<\/span> as long as <\/span>i < j<\/span>.<\/span><\/p>\n\n

Control what you read, control what you write<\/span><\/h3>\n

We have limited control over the content of the index, so we decided to focus on swapping content in nearby memory.<\/span><\/p>\n

The index is an instance of<\/span> std::vector<\/span><\/a>, and its underlying memory is allocated via<\/span> malloc<\/span><\/a>. If we could somehow create a memory layout where we control the content before or after the index, then we would be able to control what we write during a swap.<\/span><\/p>\n

An easy way to control the memory layout of malloc allocations is to use <\/span>mmap\u2019d allocation<\/span>s. For large enough allocations, malloc will<\/span> use mmap<\/span><\/a> to require more memory from the system. When mapping new memory via<\/span> mmap<\/span><\/a>, the Linux kernel will<\/span> try to expand<\/span><\/a> known mapped memory and return adjacent regions. We can exploit this logic to place individual allocations alongside.<\/span><\/p>\n

Most data structures in Hermes don\u2019t use malloc directly but instead rely on the Hermes<\/span> Garbage Collector (GC)<\/span><\/a> to allocate memory. However, Hermes\u2019s implementation of<\/span> ArrayBuffer<\/span><\/a> uses<\/span> malloc<\/span><\/a> to<\/span> allocate<\/span><\/a> their underlying data buffer.<\/span><\/p>\n\n

For our exploit, we crafted this strategic memory layout:<\/span><\/p>\n\n

To obtain it, we first created two ArrayBuffers (C and B), started sorting (thus creating the index), and finally created a third ArrayBuffer (A) from within the callback. Here, A, B, and C are the data buffers of ArrayBuffers that we control.<\/span><\/p>\n

Using our swapping capabilities, we can now swap elements of A with elements of B or C.<\/span><\/p>\n

Obtaining arbitrary reads and writes<\/span><\/h3>\n

Memory chunks allocated via malloc<\/span> embed extra metadata<\/span><\/a>, which, for instance, contains the size of the allocated region.<\/span><\/p>\n

All our memory regions (A, Index, B, and C) are contained in separate malloc chunks, each having its own header and metadata.<\/span><\/p>\n

What would happen if we swapped the size of a malloc chunk with another value?<\/span><\/p>\n\n

Swapping the size of a chunk with another value leads to some interesting results. For example, if we write a size large enough to contain both B and C and delete B\u2019s ArrayBuffer instance (thus causing its memory to be freed), then the memory of both B and C will be unmapped. However, since we never deleted C\u2019s ArrayBuffer instance, it would still be pointing to the memory (which is now invalid).<\/span><\/p>\n\n

But look what happens if we allocate a new ArrayBuffer, B\u2019, with a size matching the newly unmapped region:\u00a0<\/span><\/p>\n\n

The system will reallocate the unmapped region for B\u2019, and, as a result, B\u2019 and C will overlap.<\/span> Obtaining overlapping chunks<\/span><\/a> is a well-known heap exploitation technique and can be often used to obtain more powerful capabilities, such as arbitrary reads or writes.<\/span><\/p>\n

In this setting, we can control the content of C from B\u2019. To obtain read\/write capabilities, we can repurpose region C to host \u201csomething\u201d containing memory addresses, so that from B\u2019 we could change these to any arbitrary address.<\/span><\/p>\n

There is a way we can get <\/span>internal data structures for JS objects allocated inside C. More specifically, we can do this by using the Hermes GC. The GC is responsible for releasing or allocating memory for Hermes objects. At the time of the report, the default GC was<\/span> GenGC<\/span><\/a>, and, as outlined in the <\/span>GenGC documentation<\/span><\/a>, the space allocated by this GC:<\/span><\/p>\n

\u201c\u2026 is made out of many fixed-size regions of memory known as segments. Currently these segments are 4 MiB \u2026 Memory is acquired and released on a per-segment basis. Segments are allocated using mmap \u2026\u201d<\/span><\/p>\n

If we free C and create enough JS objects, the GC will need to allocate an extra segment (to host the new objects). The new segment will be placed in C\u2019s place (assuming C is at least 4 MiB in size).<\/span><\/p>\n

In essence, we are taking the memory previously used to hold the content of ArrayBuffer C and get Hermes to reuse it for a JS heap segment (remember the dotted section of our earlier diagram?). While doing so, we are maintaining read\/write (RW) access to the segment via B\u2019.<\/span><\/p>\n\n

Now we can overwrite the content of the segment S from B\u2019.<\/span><\/p>\n

GC segments contain plenty of JS object instances, including ArrayBuffer objects. If we spray enough ArrayBuffers, some of them will be placed in the new segment:<\/span><\/p>\n\n

To summarize, we got Hermes to reuse C\u2019s memory to host the \u201cmetadata\u201d of several other ArrayBuffers. This was possible because ArrayBuffers\u2019 contents and JS object metadata are both ultimately backed by mmap (see our earlier diagram).<\/span><\/p>\n

Each ArrayBuffer object contains a pointer to the underlying data buffer (i.e., its content).<\/span><\/p>\n

Using B\u2019, we can change the address in a chosen instance and make it point anywhere in memory instead of to their original buffer (D in the image). Then, by reading or writing to that ArrayBuffer instance, we can read or write at any arbitrary address!<\/span><\/p>\n

Putting it all together<\/h3>\n

We came a long way from a mysterious crash in <\/span>Array.prototype.sort<\/span> to obtaining unlimited R\/W capabilities.<\/span><\/p>\n

To summarize:<\/span><\/p>\n

We created a strategic memory layout of four adjacent mmap\u2019d buffers.<\/span>
\nWe used the sorting bug to swap the size of a malloc chunk and obtain two overlapping ArrayBuffers.<\/span>
\nFinally, we replaced one of the overlapping buffers with a GC segment so that we could overwrite pointers and obtain arbitrary R\/W access.<\/span><\/p>\n

A typical exploit flow would continue as follows:<\/span><\/p>\n

Write an<\/span> ROP-chain<\/span><\/a> and<\/span> shellcode<\/span><\/a> somewhere in memory.<\/span>
\nLeak some addresses to defeat<\/span> ASLR<\/span><\/a>.<\/span>
\nOverwrite function pointer with a<\/span> stack pivoting gadget<\/span><\/a>.<\/span>
\nExecute ROP-chain and make shellcode executable.<\/span>
\nJump to shellcode.<\/span>
\nProfit.<\/span><\/p>\n

We will not cover the details of the remaining steps, as they refer to well-known exploitation techniques. The final result lets us execute arbitrary code directly from Hermes and escape the JS sandbox.<\/span><\/p>\n

To make things more fun, we used our exploit to run <\/span>Doom<\/span>:<\/span><\/p>\n


\nhttps:\/\/engineering.fb.com\/wp-content\/uploads\/2022\/07\/Hermes-Quicksort-Doom.mp4<\/a><\/div>\n

Conclusion<\/h2>\n

Thanks to our bug bounty researcher\u2019s quick find and report (within six days of the bug being introduced!) and the team\u2019s work on it, this bug wasn\u2019t included in any<\/span> Hermes public releases<\/span><\/a>.<\/span><\/p>\n

Based on our internal investigation, we awarded the researcher with a $12,000 bounty. While we always perform an in-depth investigation of each bug submission, we strongly encourage researchers to dive deeper in our native products. On that note, we<\/span> award bonuses<\/span><\/a> to reports that feature a full proof of concept.<\/span><\/p>\n

This and other reports were submitted within the context of our <\/span>Hermes and SparkAR bug bounty<\/span><\/a> track, which incentivizes security research on these products.<\/span><\/p>\n\n

Since this bug was reported, we have improved our internal fuzzing effort to help find bugs earlier on, and we are currently working on hardening measures that would drastically diminish the impact of similar bugs.<\/span><\/p>\n

We encourage researchers to share their findings and work with our internal research team to test our mitigations so we can keep improving our defenses. We\u2019ll continue to share notable bugs and bug bounty reports<\/a> to celebrate the work of our community. Happy hunting!<\/span><\/p>\n

The post Using Hermes\u2019s Quicksort to run Doom: A tale of JavaScript exploitation<\/a> appeared first on Engineering at Meta<\/a>.<\/p>\n

Engineering at Meta<\/p>","protected":false},"excerpt":{"rendered":"

At Meta, our Bug Bounty program is an important element of our \u201cdefense-in-depth\u201d approach to security. Our internal product security teams investigate every bug submission to assess its maximum potential impact so that we can always reward external researchers based on both the bug they found and our further internal research assessment of where else… Continue reading Using Hermes\u2019s Quicksort to run Doom: A tale of JavaScript exploitation<\/span><\/a><\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","footnotes":""},"categories":[7],"tags":[],"class_list":["post-609","post","type-post","status-publish","format-standard","hentry","category-technology","entry"],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":610,"url":"https:\/\/fde.cat\/index.php\/2022\/07\/20\/how-meta-and-the-security-industry-collaborate-to-secure-the-internet\/","url_meta":{"origin":609,"position":0},"title":"How Meta and the security industry collaborate to secure the internet","date":"July 20, 2022","format":false,"excerpt":"Bug hunting is hard and can sometimes go unnoticed across our industry. Building scalable bug detection methods across large codebases and open source libraries is an underappreciated yet critical effort every engineering company has to work through. Because the ideal outcome is that bugs are found and fixed before they\u2026","rel":"","context":"In "Technology"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":516,"url":"https:\/\/fde.cat\/index.php\/2021\/12\/15\/charting-the-future-of-our-bug-bounty-program\/","url_meta":{"origin":609,"position":1},"title":"Charting the future of our bug bounty program","date":"December 15, 2021","format":false,"excerpt":"We\u2019re tackling the industry-wide issue of scraping by expanding our bug bounty program to reward valid reports of scraping bugs and unprotected data sets. To the best of our knowledge, this is an industry first.\u00a0 Looking toward the future, we\u2019re also launching new educational opportunities for researchers and hosting our\u2026","rel":"","context":"In "Technology"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":263,"url":"https:\/\/fde.cat\/index.php\/2021\/08\/31\/minesweeper-automates-root-cause-analysis-as-a-first-line-defense-against-bugs\/","url_meta":{"origin":609,"position":2},"title":"Minesweeper automates root cause analysis as a first-line defense against bugs","date":"August 31, 2021","format":false,"excerpt":"Root cause analysis (RCA) is an important part of fixing any bug. After all, you can\u2019t solve a problem without getting to the heart of it. But RCA isn\u2019t always simple, especially at a scale like Facebook\u2019s. When billions of people are using an app on a variety of platforms\u2026","rel":"","context":"In "Technology"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":720,"url":"https:\/\/fde.cat\/index.php\/2023\/05\/29\/sre-weekly-issue-374\/","url_meta":{"origin":609,"position":3},"title":"SRE Weekly Issue #374","date":"May 29, 2023","format":false,"excerpt":"View on sreweekly.com A message from our sponsor, Rootly: Rootly is hiring for a Sr. Developer Relations Advocate to continue helping more world-class companies like Figma, NVIDIA, Squarespace, accelerate their incident management journey. Looking for previous on-call engineers with a passion for making the world a more reliable place. Learn\u2026","rel":"","context":"In "SRE"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":492,"url":"https:\/\/fde.cat\/index.php\/2021\/10\/20\/facebook-engineers-receive-2021-ieee-computer-society-cybersecurity-award-for-static-analysis-tools\/","url_meta":{"origin":609,"position":4},"title":"Facebook engineers receive 2021 IEEE Computer Society Cybersecurity Award for static analysis tools","date":"October 20, 2021","format":false,"excerpt":"Until recently, static analysis tools weren\u2019t seen by our industry as a reliable element of securing code at scale. After nearly a decade of investing in refining these systems, I\u2019m so proud to celebrate our engineering teams today for being awarded the IEEE Computer Society\u2019s Cybersecurity Award for Practice for\u2026","rel":"","context":"In "Technology"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":519,"url":"https:\/\/fde.cat\/index.php\/2021\/12\/20\/sre-weekly-issue-301\/","url_meta":{"origin":609,"position":5},"title":"SRE Weekly Issue #301","date":"December 20, 2021","format":false,"excerpt":"View on sreweekly.com A message from our sponsor, Rootly: Manage incidents directly from Slack with Rootly \ud83d\ude92. Automate manual admin tasks like creating incident channel, Jira and Zoom, paging the right team, postmortem timeline, setting up reminders, and more. Book a demo: https:\/\/rootly.com\/demo\/?utm_source=sreweekly Articles BadgerDAO Exploit Technical Post Mortem This\u2026","rel":"","context":"In "SRE"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/posts\/609","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/comments?post=609"}],"version-history":[{"count":0,"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/posts\/609\/revisions"}],"wp:attachment":[{"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/media?parent=609"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/categories?post=609"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/tags?post=609"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}