The Backtrace I/O crash analysis platform fundamentally improves software debugging and fault detection by empowering engineers to identify root causes and trends with unparalleled efficiency

Backtrace I/O

As part of learning the Rust ecosystem, I dedicated the last few days to error management. Here are my findings. Error management 101 The describes the basics of error management. The language separates between recoverable errors and unrecoverable ones. Rust book Unrecoverable errors benefit from the macro. When panics, it stops the program. Recoverable errors are much more enjoyable. panic!() Rust Rust uses the monad, which stems from Functional Programming. Opposite to exceptions in other languages, FP mandates to return a structure that may contain the requested value the error. The language models it as an with generics on each value: Either either or enum #[derive(Copy, PartialEq, PartialOrd, Eq, Ord, Debug, Hash)]
pub enum Result<T, E> {
    Ok(T),
    Err(E),
} Because Rust manages completeness of matches, matching on enforces that you handle both branches: Result match fn_that_returns_a_result() {
    Ok(value) => do_something_with_value(value)
    Err(error) => handle_error(error)
} If you omit one of the two branches, compilation fails. The above code is safe if unwieldy. But Rust offers a full-fledged API around the struct. The API implements the monad paradigm. Result Propagating results Propagating results and errors is one of the main micro-tasks in programming. Here's a naive way to approach it: #[derive(Debug)]
struct Foo {}
#[derive(Debug)]
struct Bar { foo: Foo }
#[derive(Debug)]
struct MyErr {}

fn main() {
    print!("{:?}", a(false));
}

fn a(error: bool) -> Result<Bar, MyErr> {
    match b(error) {                                   //1
        Ok(foo) => Ok(Bar{ foo }),                     //2
        Err(my_err) => Err(my_err)                     //3
    }
}

fn b(error: bool) -> Result<Foo, MyErr> {
    if error {
        Err(MyErr {})
    } else {
        Ok(Foo {})
    }
} Return a which contains a or a Result Bar MyErr If the call is successful, unwrap the value, wrap it again, and return it Foo If it isn't, unwrap the error, wrap it again, and return it The above code is a bit verbose, and because this construct is quite widespread, Rust offers the operator: ? When applied to values of the type, it propagates errors. If the value is , then it will return from the enclosing function or closure. If applied to , then it will unwrap the value to evaluate to . Result<T, E> Err(e) Err(From::from(e)) Ok(x) x -- The question mark operator We can apply it to the above function: a fn a(error: bool) -> Result<Bar, MyErr> {
    let foo = b(error)?;
    Ok(Bar{ foo })
} The trait Error Note that enforces no bounds on the right type, the "error" type. However, Rust provides an trait. Result<T, E> Error Two widespread libraries help us manage our errors more easily. Let's detail them in turn. Implement Error trait with thiserror In the above section, I described how a could implement the trait. However, doing so requires quite a load of boilerplate code. The crate provides macros to write the code for us. Here's the documentation sample: struct Error thiserror #[derive(Error, Debug)]                                                   //1
pub enum DataStoreError {
    #[error("data store disconnected")]                                   //2
    Disconnect(#[from] io::Error),
    #[error("the data for key `{0}` is not available")]                   //3
    Redaction(String),
    #[error("invalid header (expected {expected:?}, found {found:?})")]   //4
    InvalidHeader {
        expected: String,
        found: String,
    }
} Base macro Error Static error message Dynamic error message, using field index Dynamic error message, using field name helps you generate your errors. thiserror Propagate Result with anyhow The crate offers several features: anyhow A custom struct. I will focus on this one anyhow::Result<T> A way to attach context to a function returning an anyhow::Result<T> Additional backtrace environment variables Compatibility with thiserror A macro to create errors on the fly Result propagation has one major issue: functions signature across unrelated error types. The above snippet used a single enum, but in real-world projects, errors may come from different crates. Here's an illustration: #[derive(thiserror::Error, Debug)]
pub struct ErrorX {}                                                      //1
#[derive(thiserror::Error, Debug)]
pub struct ErrorY {}                                                      //1

fn a(flag: i8) -> Result<Foo, Box<dyn std::error::Error>> {               //2
    match flag {
        1 => Err(ErrorX{}.into()),                                        //3
        2 => Err(ErrorY{}.into()),                                        //3
        _ => Ok(Foo{})
    }
} Two error types, each implemented with a different with struct thiserror Rust needs to know the size of the return type at compile time. Because the function can return either one or the other type, we must return a fixed-sized pointer; that's the point of the construct. For a discussion on when to use compared to other constructs, please read this . Box<dyn Error> Box StackOverflow question To wrap the struct into a , we rely on the method Box into() With , we can simplify the above code: anyhow fn a(flag: i8) -> anyhow::Result<Foo> {
    match flag {
        1 => Err(ErrorX{}.into()),
        2 => Err(ErrorY{}.into()),
        _ => Ok(Foo{})
} With the trait, we can improve the user experience with additional details. Context The method is evaluated lazily, while the is evaluated eagerly. with_context() context() Here's how you can use the latter: fn a(flag: i8) -> anyhow::Result<Bar> {
    let foo = b(flag).context(format!("Oopsie! {}", flag))?;              //1
    Ok(Bar{ foo })
}

fn b(flag: i8) -> anyhow::Result<Foo> {
    match flag {
        1 => Err(ErrorX{}.into()),
        2 => Err(ErrorY{}.into()),
        _ => Ok(Foo{})
    }
} If the function fails, print the additional error message with the value Oopsie! flag Conclusion Rust implements error handling via the Either monad of FP and the enum. Managing such code in bare Rust requires boilerplate code. The crate can easily implement the trait for your structs while simplifies function and method signatures. Result thiserror Error anyhow To go further: Rust error handling The Error trait anyhow crate thiserror crate What is the difference between context and with_context in anyhow? Error handling across different languages A retrospective on Errors Management: where do we go from here? Originally published at on February 11th, 2024 A Java Geek

Error Management in Rust: Libraries That Support It and Best Practices

I had an interesting problem to solve recently. Being just out of college and seeing the first instance of something that was learnt, in the real world scenario was kind of exciting. The thing is that there were occasional orders and some request getting failed within our e-commerce Rails app. From the exception handles we found out that it was caused by errors. API MySQL "Deadlock found when trying to get lock; try restarting transaction" "Lock wait timeout exceeded; try restarting transaction" This was bad as something which is an integral part of the business should not fail. So my first priority was to isolate the cause of this. From the logs, I was able to backtrace to which line of code was failing and also find out that both of the above errors were for the same line of code. So what exactly is a deadlock? Suppose there are two transactions which need to acquire some lock so that it can commit the transaction. Transaction A: Locks row X and awaits to lock row Y. Transaction B: Locks row Y and awaits to lock row X. But these two transactions holds the lock on the row that the other requires to function, thus creating a situation wherein both ceases to function. In such cases, MySQL times out one or both of the transactions and the locks are released. But the thing with Rails is that you have the ORM, transaction enclosed callbacks and I often forget about the SQL, underlying database protocols and ACID properties it has to maintain. It’s all Rails magic. To the muggle world now! Three things could be deduced now: Locks required for the failing line of code are in reverse order of what locks the other transaction needs, thus causing deadlocks. There is some heavy transaction which might be locking the table instead of the row such that orders are failed due to timeouts. As its the same line of code that is failed, a timeout error occurs when deadlock does not happen. So the next step was to find out the other transaction which is locking the rows causing timeouts and deadlocks. Troubleshooting Deadlocks: In the MySQL console execute the query: SHOW ENGINE INNODB STATUS; This gives you the state of the InnoDB storage engine. It has different sections of information among which you can find the information on latest detected deadlock. You can read more on this . here Here is a sample deadlock section: ------------------------LATEST DETECTED DEADLOCK------------------------141016 15:39:58*** (1) TRANSACTION:TRANSACTION 3D009, ACTIVE 19 sec starting index readmysql tables in use 1, locked 1LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)MySQL thread id 2, OS thread handle 0x7f0ee43cd700, query id 78 localhost rootupdatingDELETE FROM t WHERE i = 1*** (1) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 0 page no 2428 n bits 72 index `GEN_CLUST_INDEX` of table`mysql`.`t` trx id 3D009 lock_mode X waitingRecord lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 00: len 6; hex 000000000700; asc       ;;1: len 6; hex 00000003d007; asc       ;;2: len 7; hex 87000009560110; asc     V  ;;3: len 4; hex 80000001; asc     ;; *** (2) TRANSACTION:TRANSACTION 3D008, ACTIVE 69 sec starting index readmysql tables in use 1, locked 14 lock struct(s), heap size 1248, 3 row lock(s)MySQL thread id 1, OS thread handle 0x7f0ee440e700, query id 79 localhost rootupdatingDELETE FROM t WHERE i = 1*** (2) HOLDS THE LOCK(S):RECORD LOCKS space id 0 page no 2428 n bits 72 index `GEN_CLUST_INDEX` of table`mysql`.`t` trx id 3D008 lock mode SRecord lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 00: len 8; hex 73757072656d756d; asc supremum;; Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 00: len 6; hex 000000000700; asc       ;;1: len 6; hex 00000003d007; asc       ;;2: len 7; hex 87000009560110; asc     V  ;;3: len 4; hex 80000001; asc     ;; *** (2) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 0 page no 2428 n bits 72 index `GEN_CLUST_INDEX` of table`mysql`.`t` trx id 3D008 lock_mode X waitingRecord lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 00: len 6; hex 000000000700; asc       ;;1: len 6; hex 00000003d007; asc       ;;2: len 7; hex 87000009560110; asc     V  ;;3: len 4; hex 80000001; asc     ;; *** WE ROLL BACK TRANSACTION (1) I admit that I was quite overwhelmed seeing the whole bunch of information. But then, if you squint a little it all starts to make sense. Within the section you can understand what are the transactions which had caused deadlocks, the type of lock that was held and was waited for. Things you can infer from this chunk of information: : From the transaction sections you can figure out the locked index of the table more importantly, transactional query for and Transactions involved [_RECORD LOCKS_](https://dev.mysql.com/doc/refman/5.5/en/innodb-locking.html#innodb-record-locks) SPACE id 0 , WAITING FOR THIS LOCK TO BE GRANTED _HOLDS THE LOCKS(S)_ . : You can see and above_._ It’s necessary that you understand how locking works so that you you know why deadlock happened. Locks modes involved lock mode S lock mode X : A kind of that prevents any other from locking the same row. Exclusive lock (X) lock transaction : A kind of that allows other to read the locked object, and to also acquire other shared locks on it, but not to write to it. Shared lock (S) lock transactions Voila! Now you know what transactions are causing the trouble. Avoiding Deadlocks: A web application is a fairly complex system of hardware, software and networking. There can be multiple users requesting the web app simultaneously. And your app must be coded in a way such that it can handle concurrent data access. If this is not done properly it can result in time-outs and deadlocks. Also, App server can have multiple processes such that your host can run Ruby code for multiple requests concurrently. Therefore the two main tools for you to handle concurrency is transactions and locks. Keep in mind the following points to avoid deadlocks Transactions must be short — lock fewer rows for the smallest amount of time as much as possible. 2 . Care about ActiveRecord callbacks that you use. Use for a long running code. For example: after_commit class SailBoathas_many :passengersafter_create :get_passenger_listdef get_passenger_list# associating all passengersendend Now the callback opens up a transaction block for a large period of time and does associations. This is bad as this locks up rows and invites deadlocks. 3. Make sure the common workflows always acquires lock in the same order. 4. Use queues to prevent concurrent data access. 5. Check whether your Application use-case requires what mode of . By default, INNODB uses . Isolation level REPEATABLE READ Solving the issue Transactions holding the lock was from an external service that was being hit to our application. Also thanks to Unicorn, these requests happen concurrently and increases the timeout/deadlock probability. Why? Because these were heavy transaction borne requests and sometimes it goes well beyond the default 50 sec lock wait or will acquire the locks just to create a deadlock. From I was able to figure out the query that and that was from a stored procedure that the API request invoked. The lock acquisition within the order flow and the stored procedure were the reverse. Making them the same order was a lot of change. But introducing a new within the stored procedure such that, rather than joining two indexed table directly, joining it through an indexed temporary table solved the problem from re-occurring. INNODB STATUS HOLDS THE LOCK(S) TEMPORARY TABLE And for the deadlock/timeout API request that’s been failing, I simply implemented a queue with retry block and pushed them to it. Whew, I guess I am done here! It was quite a learning curve and pretty cool understanding the how database hustles around with each queries keeping true to its properties. Also feel free to correct me in case of any mistakes made or share your thoughts in the comments. Have a good day. Code Long and Prosper!

Troubleshooting and avoiding deadlocks — MySQL/Rails

wrote a brilliant about and its use in fuzzing Rust programs. Manish Goregaokar blog post cargo-fuzz Since that post, I have pushed code to update the default fuzz target template and to make the whole fuzzing experience even nicer. I also cloned a load of open-source projects and ran against them… with success! As of today, I’ve submitted 10 bugs to the ; 6 of which are fixed and 4 with open issues on the projects. cargo-fuzz trophy case If you have a project that takes input, I urge you to fuzz test your code! Anyway — this is the typical workflow I run through to test a project: $ cd <your-amazing-project>
$ cargo install cargo-fuzz # (if not already installed)
$ cargo fuzz init
$ vim fuzz/fuzzers/fuzzer_script_1.rs

<edit and save the file... more below>

$ cargo fuzz run fuzzer_script_1

<sit back and wait> … and that’s it! EDIT: has some regarding command-line flags to speed up fuzzing. /u/lifthrasiir good tips Now, in terms of what to put in the fuzz target, it’s very simple. You’re typically going to want to add code in here that is the entry point to the rest of the library. (You can, of course, test a certain feature of your program but at least here it’ll test the whole thing.) An example of such code is below: #![no_main]
#[macro_use] extern crate libfuzzer_sys;
extern crate your_lib;

fuzz_target!(|data: &[u8]| {
    let _ = your_lib::parse(data); // I added this line.
}); “… But my code doesn’t take a &[u8]”, you say — Easy, you can use the following to convert it to a &str. if let Ok(utf8) = std::str::from_utf8(data) {
    let _ = your_lib::parse(utf8);
} Now, from here you can either submit an issue to the project or fix the bug yourself. I typically use the following format to submit crashes I have found ( ): example here Found using `cargo-fuzz`.

<a minimal program (containing input) which causes the issue>

<backtrace> I’ll soon be publishing another post about analysing and fixing crashes so keep an eye out — that’s all for now, thanks guys!

How to fuzz a Rust program

Read the first part of this article here: Unveiling a 35-Year-Old Vulnerability in nix libX11: Part 1 My team recently discovered two security vulnerabilities in X.Org libX11, the widely popular graphics library – (with a high NVD severity ). These vulnerabilities cause a denial-of-service and remote code execution. X11’s latest versions contain fixes for these vulnerabilities. CVE-2023-43786 and CVE-2023-43787 CVSS 7.8 The team constantly monitors open-source projects to find new vulnerabilities and malicious packages and shares them with the wider community to help improve their overall security posture. This 2-part blog series provides details of the inner workings of the vulnerable Xpm file format and deep-dives into exploiting these vulnerabilities. This post provides a walkthrough for achieving code execution by exploiting CVE-2023-43787 on a Debian machine. RCE vulnerability – CVE-2023-43787 CVE-2023-43787 is a heap-based buffer overflow vulnerability that occurs when parsing a malformed XPM image, which can be exploited to achieve remote code execution. Fix commit: The vulnerability was fixed in libX11 version 1.8.7, in commit . 7916869d Technical analysis The root cause of CVE-2023-43787 lies in , a libX11 function that is used to create an object, representing an off-screen image that can be manipulated and displayed on the screen. With , developers can efficiently manage off-screen images in X11 applications, specifying parameters like width, height, depth, and format to customize image attributes. XCreateImage XImage XCreateImage package org.example;

import java.io.IOException;
import org.yaml.snakeyaml.LoaderOptions;
import org.yaml.snakeyaml.constructor.*;
import org.yaml.snakeyaml.Yaml;

public class Main {
    public static void main(String[] args) throws IOException {
        LoaderOptions options = new LoaderOptions();
        Yaml yaml = new Yaml(new Constructor(options));
        String strYaml = Files.readString(args[0]); 
        String parsed = yaml.load(strYaml);
    }
} XImage *XCreateImage (
    register Display *dpy,
    register Visual *visual,
    unsigned int depth,
    int format,
    int offset,
    char *data,
    unsigned int width,
    unsigned int height,
    int xpad,
    int image_bytes_per_line)
        /*How many bytes between a pixel on one line and the pixel with the same X coordinate on the next line? 0 means 	  XCreateImage can calculate it.*/
{
    register XImage *image;
    int bits_per_pixel = 1;
    int min_bytes_per_line;


    .......
    if (format == ZPixmap)
    {
       bits_per_pixel = _XGetBitsPerPixel(dpy, (int) depth); [1]
    }

    image->xoffset = offset;
    image->bitmap_pad = xpad;
    image->depth = depth;
    image->data = data;
    /*
     * compute per line accelerator.
     */
    {
    if (format == ZPixmap)
        min_bytes_per_line =                              [2]
           ROUNDUP((bits_per_pixel * width), image->bitmap_pad);
    else
        min_bytes_per_line =
            ROUNDUP((width + offset), image->bitmap_pad);
    }
     if (image_bytes_per_line == 0) {
        image->bytes_per_line = min_bytes_per_line;
    } else if (image_bytes_per_line < min_bytes_per_line) { Xfree(image); return NULL; } else { image->bytes_per_line = image_bytes_per_line;     [3]
    }
    ....... When the format is it calculates [1], and then uses the result to calculate the [2]. ZPixmap bits_per_pixel min_bytes_per_line It is then set to the attribute of the XImage [3]. bytes_per_line There is no validation on the of the image, and so the calculation [2] exceeds the capacity of (a 4-byte integer), causing an overflow. width min_bytes_per_line is called from libXpm’s function, defined in : XCreateImage CreateXImage create.c /*
 * Create an XImage with its data
 */
static int
CreateXImage(
    Display	 *display,
    Visual	 *visual,
    unsigned int  depth,
    int		  format,
    unsigned int  width,
    unsigned int  height,
    XImage	**image_return)
{
    ...

    /* then create the XImage with data = NULL and bytes_per_line = 0 */
    *image_return = XCreateImage(display, visual, depth, format, 0, 0,
                     width, height, bitmap_pad, 0);                       [1]
    if (!*image_return)
    return (XpmNoMemory);

#if !defined(FOR_MSW) && !defined(AMIGA)
    if (height != 0 && (*image_return)->bytes_per_line >= INT_MAX / height) {
        XDestroyImage(*image_return);
        *image_return = NULL;
        return XpmNoMemory;
    }
    /* now that bytes_per_line must have been set properly alloc data */
    if((*image_return)->bytes_per_line == 0 ||  height == 0) {
        XDestroyImage(*image_return);
        *image_return = NULL;
        return XpmNoMemory;
    }
    (*image_return)->data =
        (char *) XpmMalloc((*image_return)->bytes_per_line * height);     [2]

    ...
} On [1] there’s the call to the vulnerable function that calculates the size needed to be allocated. XCreateImage On [2] there’s an allocation that uses the overflown property of the XImage, which will then proceed to allocate a smaller buffer than needed. bytes_per_line is called from the function [1], triggered when libXPM is asked to parse an XPM file: CreateXImage xpmParseDataAndCreate /*
 * This function parses an Xpm file or data and directly create an XImage
 */
int
xpmParseDataAndCreate(
    Display		 *display,
    xpmData		 *data,
    XImage		**image_return,
    XImage		**shapeimage_return,
    XpmImage		 *image,
    XpmInfo		 *info,
    XpmAttributes	 *attributes)
{
    


   .....

    /*
     * parse the header
     */
    ErrorStatus = xpmParseHeader(data);
    if (ErrorStatus != XpmSuccess)
        return (ErrorStatus);

    /*
     * read values
     */
    ErrorStatus = xpmParseValues(data, &width, &height, &ncolors, &cpp,
                 &x_hotspot, &y_hotspot, &hotspot,
                 &extensions);
    if (ErrorStatus != XpmSuccess)
        return (ErrorStatus);

   .........

    /* now create the ximage */
    if (image_return) {
        ErrorStatus = CreateXImage(display, visual, depth,
                       (depth == 1 ? bitmap_format : ZPixmap),
                       width, height, &ximage);                       [1]
    if (ErrorStatus != XpmSuccess)
        RETURN(ErrorStatus);
        ......... Exploiting CVE-2023-43787 to achieve code execution Let’s discuss all the basic exploitation pieces before moving on to code execution. Piece 1 – Controlling the allocation size The size of the allocation that is overflown, is decided from the width of the Xpm image. As we discussed in the previous blog post, the width can be easily manipulated by modifying this information in the Xpm header. So, we have control over the allocation size (heap bin size). We now want to find out how to control the overflown data. Piece 2 – Controlling the overflowed buffer data The overflown data is , which is the pointer to the image data. ximage->data Piece 3 – Controlling the overflow size Controlling the size of the overflow itself (anything that comes after the allocated buffer). This is easily achieved as Xpm reads the image pixels from the file as long as there are pixels to read. The function calls the function with the ximage object [1]: xpmParseDataAndCreate ParseAndPutPixels .....
    /*
     * read pixels and put them in the XImage
     */
    ErrorStatus = ParseAndPutPixels(
#ifdef FOR_MSW
                    display,
#endif
                    data, width, height, ncolors, cpp,
                    colorTable, &hashtable,
                    ximage, image_pixels,                      [1]
                    shapeimage, mask_pixels);
..... The ParseAndPutPixels function loops over the image pixels and fills the ximage->data: .....
        for (x = 0; x < width; x++) {                                  [1]
            int c = xpmGetC(data);                                      [2]
..... On [1], we can see the loop reads data according to , which is very big (as we needed to overflow the size). On [2], a call to the macro is made: width xpmGetC #define xpmGetC(mdata) \
    ((!mdata->type || mdata->type == XPMBUFFER) ? \
    (*mdata->cptr++) : (getc(mdata->stream.file))) Multiple Avenues of Exploitation After going over the basic exploitation pieces, let’s see which primitives can be triggered by overwriting different heap chunks. Specifically, we will examine the case of exploitation when the vulnerability is triggered through the CLI utility (for example, using the simple command-line . These exploitation avenues can be extrapolated to other vulnerable cases as well (ex. exploiting code that uses the library’s vulnerable functions) – sxpm sxpm attacker_image.xpm) Option #1 – Function pointer overwrite – Code Execution #1 Due to time constraints, we opted to switch from a 64-bit binary to 32-bit for this exploitation (which would have required more research into the pixel data). Exploitation with Option #1 will focus on Debian 12 32-bit, but the ideas apply similarly to 64-bit. If we set our overflown bin to 428 bytes ( bin), something interesting happens. 0x1b0 (Display) pointer, which is later used when freeing the XPM colors. We managed to overwrite the dpy The structure size is 2,412 bytes – allocated on the large bin. Display 0x970 Specifically, we overwrite the pointer in this structure: lock_fns struct _XLockPtrs *lock_fns; /* pointers to threads functions */ The libX11 code dereferences this pointer and jumps to the address inside it – int
XFreeColors(
    register Display *dpy,
    Colormap cmap,
    unsigned long *pixels, /* LISTofCARD32 */
    int npixels,
    unsigned long planes) /* CARD32 */
{
    register xFreeColorsReq *req;
    register long nbytes;

    LockDisplay(dpy);                                                          [1]
    GetReq(FreeColors, req);
    req->cmap = cmap;
    req->planeMask = planes;

    /* on the VAX, each pixel is a 32-bit (unsigned) integer */
    req->length += npixels;

    nbytes = npixels << 2;		/* watch out for macros... */
    Data32 (dpy, (long *) pixels, nbytes);
    UnlockDisplay(dpy);
    SyncHandle();
    return 1;
} on [1] is a macro: LockDisplay /* used everywhere, so must be fast if not using threads */
#define LockDisplay(d)	     if ((d)->lock_fns) (*(d)->lock_fns->lock_display)(d) As can be seen from the macro, when we overwrite the pointer, it will be dereferenced twice and run the resulting pointer, leading to code execution. dpy After checking the offset of in our payload, and setting its pointer to a predictable address in the 32-bit memory space of (e.g. ), we have total control over EIP. dpy->lock_fns sxpm 0x409774 Option #2 – Limited Write-What-Where Another possible primitive is to overwrite a pointer to the File Descriptor (in an structure). This happens when we allocate 136 bytes (on the fastbin). xpmData 0x90 Inside the loop that reads each character from the XMP file, it uses it and reads a character. The structure: xpmData This is a limited relative write-what-where. We can write 4 bytes (3 controlled bytes + 1 byte fixed ’00’), into a relative address like 0x5555{00414243}. This can be seen here in [1] and [2]: static int
ParseAndPutPixels(
#ifdef FOR_MSW
    Display		*dc,
#endif
    xpmData		*data,
    unsigned int	 width,
    unsigned int	 height,
    unsigned int	 ncolors,
    unsigned int	 cpp,
    XpmColor		*colorTable,
    xpmHashTable	*hashtable,
    XImage		*image,
    Pixel		*image_pixels,
    XImage		*shapeimage,
    Pixel		*shape_pixels)
{
    unsigned int a, x, y;

    switch (cpp) {

    case (1):				/* Optimize for single character
                     * colors */
    {
        unsigned short colidx[256];
#ifdef FOR_MSW
        HDC shapedc;
        HBITMAP obm, sobm;

        if ( shapeimage ) {
            shapedc = CreateCompatibleDC(*dc);
            sobm = SelectObject(shapedc, shapeimage->bitmap);
        } else {
            shapedc = NULL;
        }
        obm = SelectObject(*dc, image->bitmap);
#endif
        if (ncolors > 256)
            return (XpmFileInvalid);
        bzero((char *)colidx, 256 * sizeof(short));
        for (a = 0; a < ncolors; a++) {
            colidx[(unsigned char)colorTable[a].string[0]] = a + 1;
        }

        for (y = 0; y < height; y++) {
            xpmNextString(data);
            for (x = 0; x < width; x++) { int c = xpmGetC(data); [1] if (c > 0 && c < 256 && colidx[c] != 0) {
#ifndef FOR_MSW
                    XPutPixel(image, x, y, image_pixels[colidx[c] - 1]); [2]
                    if (shapeimage) {
                        XPutPixel(shapeimage, x, y,
                            shape_pixels[colidx[c] - 1]);
                    }
#else
                    SetPixel(*dc, x, y, image_pixels[colidx[c] - 1]);
                    if (shapedc) {
                        SetPixel(shapedc, x, y, shape_pixels[colidx[c] - 1]);
                    }
#endif
                }else {
                    return (XpmFileInvalid);
                }
            }
        }
        ...... Option #3 – Code Execution Alternative When allocating a chunk of 136 bytes (which gets allocated on the 0x90 heap fastbin), we can overwrite an object: _XLockInfo The object: structure is 192 bytes long, so it gets allocated on the bin. _XLockInfo dpy->lock 0xd0 As can be seen from the backtrace, we overwrote the that gets used in the function, which then gets accessed at the start of the function (using the register): mutex __pthread_mutex_lock rdi int
__pthread_mutex_lock (pthread_mutex_t *mutex)
{
  unsigned int type = PTHREAD_MUTEX_TYPE_ELISION (mutex);
  .....
}


#define PTHREAD_MUTEX_TYPE_ELISION(m) \
  ((m)->__data.__kind & (127|PTHREAD_MUTEX_ELISION_NP)) This is called when freeing the colors structure in , which calls the function. xpmParseDataAndCreate XFreeColors After the Mutex is accessed, the data is then used in the function: _XDisplayLockWait static void _XDisplayLockWait(
    Display *dpy)
{
    xthread_t self;

    while (dpy->lock->locking_level > 0) {
        self = xthread_self();
        if (xthread_equal(dpy->lock->locking_thread, self))
            break;
        ConditionWait(dpy, dpy->lock->cv);
    }
} The is a macro: ConditionWait #define ConditionWait(d,c) if ((d)->lock) \
    (*(d)->lock->condition_wait)(c, (d)->lock->mutex) It dereferences the lock object and then . executes it as a function This can be used as another code execution primitive. Option #4 – Another Write-What-Where (dead end in the case of sxpm) Another primitive will overwrite the structure (which is 136 bytes long – bin). XImage 0x90 This is when allocating a chunk of 16 bytes (on the fastbin). 0x20 Our image data ( ) is allocated just before the contents, and so we overwrite the pointer with our data to create this primitive. ximage->data XImage ximage->data This can be an absolute write-what-where primitive. Again, switching from a 64-bit binary to 32-bit. The rest of the exploitation will focus on Debian 12 32-bit. The structure on 32-bit is 88 bytes long. Let’s try changing the size of our overflowing buffer to 88: Contrary to the 64-bit primitive, on 32-bit our overflowing buffer is allocated after the target object. XImage XImage The allocation will be adjacent to the structure, but in the reverse order (a bit after the address). ximage->data XImage XImage Therefore – our overflown buffer will not be behind our target XImage structure, and our exploitation won’t work. Using debug prints: Now, let’s groom the heap using an allocation primitive. There are 4 pixel allocations using the following calculation: sizeof(Pixel) * ncolors On 32-bit, equals 4. sizeof(Pixel) Let’s change the file to have only 22 colors, to achieve our needed 88 bytes (22*4). Changing to 22 colors will still not help us overwrite the XImage object. Using debug prints: In the case of , this led us to a dead-end (It would be better to create a new exploitation primitive) however this chain of primitives might be relevant in different exploitation scenarios. sxpm In which cases can CVE-2023-43787 be triggered? Any application or library that uses libXPM to parse externally-supplied XPM images, can trigger CVE-2023-43787 with the use of the following vulnerable libXPM exported functions: XpmCreateImageFromXpmImage
XpmCreateImageFromBuffer
XpmCreateImageFromData
XpmCreatePixmapFromXpmImage
XpmCreatePixmapFromBuffer
XpmCreatePixmapFromData
XpmReadFileToImage
XpmReadFileToPixmap For example, is a CLI utility that is used to display XPM images on the screen. The vulnerability can be triggered via with a simple command line – sxpm sxpm sxpm attacker_image.xpm This utility calls the vulnerable libXpm function, which then calls the vulnerable libX11 functions then . xpmCreatePixmapFromImage XPutImage PutSubImage

Uncovering and Exploiting a 35-Year-Old Vulnerability, *nix libX11: Part 2 

14 Ruby FAQs and Answers 

JSWorld Conference 2022: Part IV

I am writing this article as a future reference to myself; hopefully, it will be of some help to anyone who is reading. While at Bootcamp, you tend to build your own projects and debugging those is fairly easy. The team I'm currently working on is using Rails as a back-end and a mixture of rails and VueJs for the front-end. Debugging in a docker container isn't that straightforward. At least it is not in the way my team set everything up. For starters, does not work inside a container. I also had to struggle for the first month because usage was not that straightforward to me. debugger binding.pry I will describe the methods for debugging I got to use. If you know others please do share, I will add them to the list as well: TDD with binding.pry You need to have the 'pry-rails' gem installed. Binding pry won't stop the execution of your code, but you can still use it by running your tests in the container. TDD is the golden standard and it works great in a Rails container. It works by placing inside your code and running the tests. The tests should stop at the statement in the code. If it doesn't, then you know that the method was not reached. I like this method because I am bad at writing tests. I can debug my tests or my code with it. binding.pry binding.pry Raise inspect TDD is the way to go, but it is practically impossible to cover everything with tests. This is a trick that I love to use when I want to check out something quick. It works by placing a raise method at the desired stopping point. The raise method takes as an argument the object you would like to check and send it the message. .inspect For example . Example below: raise name_of_your_method_or_variable.inspect Since your code is inside a docker container, nothing will happen in the browser window. The only way to see your error is by going to your browser's Inspect -> Network. Repeat the request that you know will go through the function you placed the raise statement in. Make the request once and see the error displayed in the Preview tab. Example below: This is a nifty trick that can save you a lot of time. Suppose you are working on a feature in an application and you have to fill out a lot of required fields. When you press submit, your fields are being emptied. You would have to refill all those fields just to test once. That is a big waste of time. In the Chrome Inspection tool inside the Network tab, you can make a request once. Placing your mouse over the response, right-clicking on it and choosing replayXHR. The browser will repeat the request. I was often told to read the backtrace, yet no one had explained what it meant. It can be intimidating when you don't know the ins and outs of a Rails application. Reading it is actually very straightforward, from bottom to top. Going through the backtrace you stop at the methods of the file that you modified and looks familiar. Other than the migrations they are usually at the top. You get a lot of valuable information not only the filename name of the method but also the line number. Debugging with binding.pry_remote For some reason, doesn't stop execution in a container. Our team is using another gem called pry-remote. You would put wherever you would normally put . Making the request, the app will look like it is being loaded, but nothing will happen. Running pry-remote in the shell of the rails container will then connect to the session. You will be able to interact with pry as you normally would. binding.pry binding.remote_pry binding.pry Debugging with Rails.logger.info To be honest, I stumbled on this method while writing this article. I haven't used it in day-to day work. As I understood from the documentation, there is a need for an initial setup which I didn't do. The way I used it is placing ("--------------------------#{name_of_the_object}----------------------")  like in the image below. Rails.logger.info I guess you can debug using this method. The only downside for me is that it gets kind of hard to find in the container logs, hence the dashes. See the image below. Perhaps I am using it wrong more research is needed. Final thoughts Take this article with a grain of salt. This is my experience working with docker containers. Your set-up may differ from mine and something might not work. I assume every developer has a favourite set of tools and methods that he likes to use. I am interested to know what is yours.

How to Use binding.pry to Debug a Rails Application in a Docker Container

Tips that would help you build integration tests using RSpec and Capybara. Integration testing can be intimidating to some, the idea of having to build test cases for the way your controllers are communicating with your view and model could make the best of us scratch our heads. But these are actually the easiest test cases to build and in this post, you’ll find some of the tricks I used to not scratch my head that much. For starters we need to know the definition of integration testing, Albert Einstein once said: “once you know exactly what to do you already solved 90% of your problem.” He didn’t quite say it that way but let us jump to the definition, shall we? Integration testing This s’ definition fits the most with what I’m trying to say: article While unit tests make sure that individual parts of your application work, integration tests are used to test that different parts of your application work together. They are normally used to test at least the most important workflows of applications. Even though you need your model, controller, and view, by the time you get to testing integration your application would already have a basic workflow (even if you used ) and if there is some feature your application is lacking off, just like unit testing, integration testing will help you fill in this gaps and build a solid workflow. TDD So without further ado let’s talk about the workflow Get started with Workflow This is a simple exercise lot’s of us ignore but to know the workflow of an application we have to yes you got it use it! When building test cases you are not just the programmer but the user as well, think of an application like let's say twitter what is the first thing it pops up when you open the browser with twitter I think you got it but here is an image The login and signup are the first workflow features you’ll see in many applications and the test cases for them are relatively easy to build. Up next I’ll describe a couple of test cases I build for a Twitter-based project I made while I was a student in . I will only focus on a couple of them because most of them are repetitive so I think it’s enough for you to build awesome test cases as well. Microverse Prerequisites and are both Ruby gems for testing so I figure you have your own Ruby on Rails application and some unit test cases for it working already, if not you can clone or download my and you’ll find instructions on how to run the app and the test cases on your computer (thank you for leaving a star in the project if you like it!). Rspec Capybara Workagram! Install and Configure Capybara Like I said before to keep going you need to have Rspec and Capybara already installed so if you do you can skip this step but if something is not working properly here is how I installed and configured both Rspec and Capybara I followed this to install and configure both Rspec and Capybara if you already have Rspec still you’d need to change some configuration files. article I won’t share the commands here but this is how my configuration files look like at the end so make sure yours do too: source git_source( ) { }

.
.
.

group , .
  .
  .
  gem .
.
.
group gem , gem . .
.
. 'https://rubygems.org' :github |repo| "https://github.com/ .git" #{repo} :development :test do 'rspec-rails' end :test do # Adds support for Capybara system testing and selenium driver 'capybara' '>= 2.15' 'selenium-webdriver' end Gemfile.rb RSpec.configure config.expect_with expectations.include_chain_clauses_in_custom_matcher_descriptions = config.mock_with mocks.verify_partial_doubles = config.shared_context_metadata_behavior = config.filter_run_when_matching config.example_status_persistence_file_path = config.disable_monkey_patching!
  config.default_formatter = config.files_to_run.one?
  config.order = Kernel.srand config.seed # This file was generated by the `rspec --init` command. Conventionally, all # specs live under a `spec` directory, which RSpec adds to the `$LOAD_PATH`. # The generated `.rspec` file contains `--require spec_helper` which will cause # this file to always be loaded, without a need to explicitly require it in any # files. # # Given that it is always loaded, you are encouraged to keep this file as # light-weight as possible. Requiring heavyweight dependencies from this file # will add to the boot time of your test suite on EVERY test run, even for an # individual file that may not need all of that loaded. Instead, consider making # a separate helper file that requires the additional dependencies and performs # the additional setup, and require it from the spec files that actually need # it. # # See http://rubydoc.info/gems/rspec-core/RSpec/Core/Configuration do |config| # rspec-expectations config goes here. You can use an alternate # assertion/expectation library such as wrong or the stdlib/minitest # assertions if you prefer. :rspec do |expectations| # This option will default to `true` in RSpec 4. It makes the `description` # and `failure_message` of custom matchers include text for helper methods # defined using `chain`, e.g.: #     be_bigger_than(2).and_smaller_than(4).description #     # => "be bigger than 2 and smaller than 4" # ...rather than: #     # => "be bigger than 2" true end # rspec-mocks config goes here. You can use an alternate test double # library (such as bogus or mocha) by changing the `mock_with` option here. :rspec do |mocks| # Prevents you from mocking or stubbing a method that does not exist on # a real object. This is generally recommended, and will default to # `true` in RSpec 4. true end # This option will default to `:apply_to_host_groups` in RSpec 4 (and will # have no way to turn it off -- the option exists only for backwards # compatibility in RSpec 3). It causes shared context metadata to be # inherited by the metadata hash of host groups and examples, rather than # triggering implicit auto-inclusion in groups with matching metadata. :apply_to_host_groups :focus 'spec/examples.txt' 'doc' if :random # The settings below are suggested to provide a good initial experience # with RSpec, but feel free to customize to your heart's content. #   # This allows you to limit a spec run to individual examples or groups #   # you care about by tagging them with `:focus` metadata. When nothing #   # is tagged with `:focus`, all examples get run. RSpec also provides #   # aliases for `it`, `describe`, and `context` that include `:focus` #   # metadata: `fit`, `fdescribe` and `fcontext`, respectively. #   config.filter_run_when_matching :focus # #   # Allows RSpec to persist some state between runs in order to support #   # the `--only-failures` and `--next-failure` CLI options. We recommend #   # you configure your source control system to ignore this file. #   config.example_status_persistence_file_path = "spec/examples.txt" # #   # Limits the available syntax to the non-monkey patched syntax that is #   # recommended. For more details, see: #   #   - http://rspec.info/blog/2012/06/rspecs-new-expectation-syntax/ #   #   - http://www.teaisaweso.me/blog/2013/05/27/rspecs-new-message-expectation-syntax/ #   #   - http://rspec.info/blog/2014/05/notable-changes-in-rspec-3/#zero-monkey-patching-mode #   config.disable_monkey_patching! # #   # This setting enables warnings. It's recommended, but in some cases may #   # be too noisy due to issues in dependencies. #   config.warnings = true # #   # Many RSpec users commonly either run the entire suite or an individual #   # file, and it's useful to allow more verbose output when running an #   # individual spec file. #   if config.files_to_run.one? #     # Use the documentation formatter for detailed output, #     # unless a formatter has already been configured #     # (e.g. via a command-line flag). #     config.default_formatter = "doc" #   end # #   # Print the 10 slowest examples and example groups at the #   # end of the spec run, to help surface which specs are running #   # particularly slow. #   config.profile_examples = 10 # #   # Run specs in random order to surface order dependencies. If you find an #   # order dependency and want to debug it, you can fix the order by providing #   # the seed, which is printed after each run. #   #     --seed 1234 #   config.order = :random # #   # Seed global randomization in this process using the `--seed` CLI option. #   # Setting this allows you to use `--seed` to deterministically reproduce #   # test failures related to randomization by passing the same `--seed` value #   # as the one that triggered the failure. #   Kernel.srand config.seed end spec/spec_helper.rb ENV[ ] = File.expand_path( , __dir_ ) abort( ) Rails.env.production? ActiveRecord::Migration.maintain_test_schema! ActiveRecord::PendingMigrationError => e
  puts e.to_s.strip
  exit Capybara.register_driver Capybara::Selenium::Driver.new(app, ) Capybara.javascript_driver = RSpec.configure config.fixture_path = config.use_transactional_fixtures = config.infer_spec_type_from_file_location! config.filter_rails_from_backtrace! config.before( ) DatabaseCleaner.clean_with( ) config.before( ) DatabaseCleaner.strategy = config.before( , ) DatabaseCleaner.strategy = config.before( ) DatabaseCleaner.start config.after( ) DatabaseCleaner.clean # This file is copied to spec/ when you run 'rails generate rspec:install' require 'spec_helper' require 'capybara/rspec' 'RAILS_ENV' || 'test' require '../config/environment' _ # Prevent database truncation if the environment is production 'The Rails environment is running in production mode!' if require 'rspec/rails' # Add additional requires below this line. Rails is not loaded until this point! # Requires supporting ruby files with custom matchers and macros, etc, in # spec/support/ and its subdirectories. Files matching `spec/**/*_spec.rb` are # run as spec files by default. This means that files in spec/support that end # in _spec.rb will both be required and run as specs, causing the specs to be # run twice. It is recommended that you do not name files matching this glob to # end with _spec.rb. You can configure this pattern with the --pattern # option on the command line or in ~/.rspec, .rspec or `.rspec-local`. # # The following line is provided for convenience purposes. It has the downside # of increasing the boot-up time by auto-requiring all files in the support # directory. Alternatively, in the individual `*_spec.rb` files, manually # require only the support files necessary. # # Dir[Rails.root.join('spec', 'support', '**', '*.rb')].each { |f| require f } # Checks for pending migrations and applies them before tests are run. # If you are not using ActiveRecord, you can remove these lines. begin rescue 1 end :selenium_chrome do |app| browser: :chrome end :selenium_chrome do |config| # Remove this line if you're not using ActiveRecord or ActiveRecord fixtures " /spec/fixtures" #{ .root} : :Rails # If you're not using ActiveRecord, or you'd prefer not to run each of your # examples within a transaction, remove the following line or assign false # instead of true. false # RSpec Rails can automatically mix in different behaviours to your tests # based on their file location, for example enabling you to call `get` and # `post` in specs under `spec/controllers`. # # You can disable this behaviour by removing the line below, and instead # explicitly tag your specs with their type, e.g.: # #     RSpec.describe UsersController, :type => :controller do #       # ... #     end # # The different available types are documented in the features, such as in # https://relishapp.com/rspec/rspec-rails/docs # Filter lines from Rails gems in backtraces. # arbitrary gems may also be filtered via: # config.filter_gems_from_backtrace("gem name") :suite do :truncation end :each do :transaction end :each js: true do :truncation end # This block must be here, do not combine with the other `before(:each)` block. # This makes it so Capybara can see the database. :each do end :each do end end spec/rails_helper.rb remember to run ‘bundle install’ after modifying the Gemfile if still doesn’t work you can look for the in my Workagram! repository complete Gemfile Authentication If your application supports users this is the most important and the first feature to test, because all the other features of your application will depend on a user to be logged in to be able to access them. Many applications would take a username and a password to log in a user but my Workagram! login only requires the Username, the code for this test case is pretty straight forward: RSpec.describe , let( ) { User.create( , ) }

  scenario visit root_path fill_in , user.username click_button sleep( ) expect(page).to have_content( ) click_on sleep( )
    expect(page). to have_content( ) 'login followed by logout' type: :feature do # The user must exist so we are creating it here :user username: 'maruk' fullname: 'Maria Eugenia Queme' 'login page' do # First we need to be in the root path # Secondly fill in the fields in this case only the username 'session_username' with: # Third we have to click the Log in button 'Log in' # We give it some time to load 3 # And lastly we are expecting our page to have the success message 'User Logged in' # Logging out it's much simplier after this 'Log out' 3 'Please log in' end end I’ve put comments to guide you through it but what I like the most about Capybara is that the commands are plain English instructions as you can see: visit, fill_in, click_button can’t get any easier than that! Awesome tip #1: sometimes we struggle knowing the names of the fields, how do we know we have to fill_in ‘session_username’ you’d ask, for that we can check it out with your browser’s developer tools inspecting the field and use what’s in the id selector. After building the authentication test case you can test everything else in no particular order, anything that looks like a form or requires to fill in a field and/or has a submit button should be tested (i.e sign up form, edit users’ info, post something, follow users, unfollow users, etc..). Lastly, I’m gonna show you how I build a test case to validate the posting feature of my Workagram! Posting feature I chose the posting feature to show next because of the posts in my Workagram! require an image similar to an Instagram post and I struggled a little when building this test case so I think these tips could be helpful for your own application, here is the code: RSpec.describe , let( ) { User.create( , ) } let( ) { }

  scenario visit root_path
    fill_in , user.username
    click_button sleep( ) expect(page). to have_content( ) attach_file , picture click_button sleep( ) expect(page). to have_content( ) expect(page).to have_css( ) 'Home management' type: :feature do # We need to create an user to authenticate :user username: 'maruk' fullname: 'Maria Eugenia Queme' # The image has to be saved somewhere in your project :picture 'app/assets/images/1000.png' 'Create valid work' do # Log in the user 'session_username' with: 'Log in' 3 # if succesfull we'll be in the main page 'WORKAGRAM SOMETHING' # We only need to attach a picture to post a job, the text is optional 'work_picture' # click on the Post button 'Post' # We let the page load for a while 3 # If everything went well it's expecting the success message to display on screen 'Work created!' # Also the main page would have to include the image of the post we just added "img[src*='1000.png']" end end Now that we have the authentication test case we‘ll need to put the code for it in every feature of our application otherwise we would have authentication errors. Awesome tip #2: We also need a variable to hold the picture’s location (it’s better if it’s within your project so your test cases work in other computers) Awesome tip #3: I use the “have_css” Capybara method when trying to validate anything that wasn’t plain text. That’s it! If you got this far I have to say you have enough to build your own test cases but if you still want to check out a couple more you can find them in my Workagram! Til the next time claps to you!

BACKTRACE I/O

backtrace.io

-- employees

Since n.d.

COMPANY RANKING

BACKTRACE I/O

EVERGREEN INDEX #2218

Representing this company? Click here to claim and customize this page!

Backtrace I/O WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

BACKTRACE I/O

backtrace.io

-- employees

Since n.d.

COMPANY RANKING

BACKTRACE I/O

EVERGREEN INDEX #2218

RELATED COMPANIESRANK

STORIES ABOUT BACKTRACE I/O

Representing this company? Click here to claim and customize this page!

Backtrace I/O WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!