As a regular reminder, it is a bad idea to give me ideas. Today's bad idea is brought to you by managerial nerd sniping, insomnia, and the letter "Q".

At a high level: writing complicated data structures in JavaScript kinda sucks. Here's an example of the kinds of things that I've been writing as I go down the ElasticSearch tour-de-insanite:

{
  highlight: {
    pre_tags: ['<em>'],
    post_tags: ['</em>'],
    require_field_match: false,
    fields: {
      body_content: {
        fragment_size: 200,
        number_of_fragments: 1,
      },
    },
  },
}

This works, this is perfectly valid code. It creates an object that has a few nested layers of stuff in it, but overall I just don't like how it looks. I think it looks superfluous. What if we could make it look a little bit nicer? How about something like this?

{
  highlight = {
    pre_tags = [ "em" ];
    post_tags = [ "</em>" ];
    require_fields_match = false;
    fields.body_content.fragment_size = 200;
    fields.body_content.number_of_fragments = 1;
  };
}

This is a Nix expression. It's a data structure that looks like JSON, but you have the power of a programming language at your fingertips. Note the difference between these two parts:

{
  fields: {
    body_content: {
      fragment_size: 200,
      number_of_fragments: 1,
    },
  },
}

{
  fields.body_content.fragment_size = 200;
  fields.body_content.number_of_fragments = 1;
}

These are semantically equal, but you don't have to use so much indentation and layering. These settings are all related, so it makes sense that the way that you use them is on the same level as the way that you define them.

If you want to try out this awesome power for yourself, Install Nix and then add @xeserv/nixexpr to your JavaScript dependencies.

npm install --save @xeserv/nixexpr

Then you can use it like this:

import { nix } from "@xeserv/nixexpr";

const someValue = "this is a string";

const myData = nix`{
    hello = "world";
    someValue = ${someValue};
}`;

console.log(myData);

I originally wrote this in Go for my scripting automation tool named yeet, but I think it's generically useful enough to exist in its own right in JavaScript. I think that there's a lot of things that the JavaScript ecosystem can gain from Nix, and I'm excited to see what people do with this.

This was made so I could write scripts like this:

// snipped for brevity
const url = slug.push("within.website");
const hash = nix.hashURL(url);

const expr = nix.expr`{ stdenv }:

stdenv.mkDerivation {
  name = "within.website";
  src = builtins.fetchurl {
    url = ${url};
    sha256 = ${hash};
  };

  phases = "installPhase";

  installPhase = ''
    tar xf $src
    mkdir -p $out/bin
    cp web $out/bin/withinwebsite
    cp config.ts $out/config.ts
  '';
}
`;

And then I'd be able to put that Nix expression into a file. I'll get into more details about this in a future post.

<Mara> Something something this isn't best practice something something this is a hack to make dealing with a legacy deployment easier something something

How it works

This is a very cheeky library, and it's all powered by one of the most fun to abuse Nix functions ever: builtins.fromJSON. This function takes a string and turns it into a Nix value at the interpreter level and it's part of the callpath for turning a string into an integer in Nix. It's an amazingly powerful function in its own right, but it gets even more fun when we bring JavaScript into the mix.

Any JavaScript data value (simple objects, strings, numbers, etc) can be formatted as JSON with the JSON.stringify function:

> JSON.stringify({"hi": "there"})
'{"hi":"there"}'

This includes strings. So if we use JSON.stringify to convert it to a JSON string, then string encode it again, we can inject arbitrary JavaScript code into Nix expressions:

let formattedValue = `(builtins.fromJSON ${
  JSON.stringify(JSON.stringify(value))
})`;

The most horrifying part about this hack is that it works.

What's next?

If this ends up getting used, I may try and make "fast paths" for strings and numbers so that they don't have to go through the JSON encoding/decoding process. But so far this works well enough for my purposes.

tl;dr: If you host eepsites with Java i2p and are running older than i2p 2.3.0, update it as soon as possible. More details below.

A sufficiently determined attacker may be able to de-anonymize the public IPv4 and IPv6 addresses of i2p hidden services (eepsites) by using a combination of brute-forcing the entire i2p router set with a replayed message. This is CVE-2023-36325.

This issue was originally discovered by a user with the identifier hbapm6le75xwc342hnkltwfnnmt4ccafr5wyf7b6jhw6jxn3fwqa.b32.i2p, which I will refer to as "hbapm6". While hbapm6 was working on a custom version of i2p, they found that replaying messages sent down client tunnels to target i2p routers could cause the i2p software to drop the packet instead of sending a "wrong destination" response. This can lead to de-anonymization of a given eepsite by being able to correlate the public IPv4 or IPv6 address of the contacted router with packets being dropped.

This is fixed in i2p 2.3.0 by adding a unique identifier to every message ID and separating out bloom filters and other datastores so that such correlation attacks are harder to pull off in the future. These changes are protocol-compatible and all users are encouraged to apply them as soon as possible.

There is insufficent data as to what versions of i2p are vulnerable, but we are certain that 2.2.1 is vulnerable. It is likely that older versions of i2p are also vulnerable. Assume so.

This attack takes days to complete and requires a fairly detailed amount of knowledge of the i2p protocol in order to successfully de-anonymize target eepsites.

Users of i2pd are not affected.

With this understood, here is the CVSS score breakdown for this attack:

AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N/E:P/RL:O/RC:C/CR:M/IR:X/AR:X/MAV:N/MAC:H/MPR:N/MUI:N/MS:U/MC:L/MI:N/MA:N

Affected users should update to i2p 2.3.0 as soon as it is available.

The vulnerability has been mitigated by a refactor of the relevant codepaths involved with message parsing. Additionally, the network information database was sharded off with the hope of preventing future attacks.

On a side note, I have been very impressed with the i2p projects handling of the circumstances surrounding hbapm6 of the issues tracked as CVE-2023-36325. For an unknown reason, hbapm6 decided that the best way to get attention for these issues was to impersonate me. I was contacted by the i2p project due to hbapm6 acting very strange (IE: claiming to have a vuln and refusing to show proof of it or how they triggered it, if you have a de-anonymization attack for such a network, just share your code and demonstrate it when asked, it will save so much time for everyone involved), and after a month or two of cajoling, hbapm6 eventually managed to de-anonymize a throwaway VPS that was acting as an i2p router. This confirmed the vuln and lead to me filing this CVE.

I guess this is part of my threat profile now. Fun.

At the very least I got to have a conversation that was like (names have been changed to protect the innocent):

(hbapm6); Why all the snooping? [...] What is this, a game of Among Us?

(Me) <link to my website to an ascii art of an amogus with proof that I am the actual Xe Iaso>

I still have no idea why that person impersonated me. If you're out there and reading this and I wronged you somehow, I'm sorry and would like to know what I fucked up so I can change for the better.

There's some other vulnerabilities that are related to this, but none of them have viable attacks. Most of the changes being done are just various hardening to the pokey edges of the network database and other things. I expect that these are fairly minor issues and when the patch comes out you should probably update.

Sometimes you need to dump your system logs for a developer of an application to understand why things are failing. sysdiagnose lets you have your iDevice emit a giant tarball of information so that they can pick out what the problem is.

However, their official button pressing procedure is finicky and doesn't give confirmation that anything is happening. Here's how you unconditionally force your iPad to do a sysdiagnose:

• Remove your iPad from the keyboard dock
• Disable Stage Manager
• Open Settings
• Tap Accessibility
• Tap Touch
• Tap AssistiveTouch
• Enable it
• Tap Customize Top Level Menu
• Add another icon
• Tap the empty icon
• Choose Analytics
• Swipe up to the home screen
• Tap the AssistiveTouch button
• Tap Analytics
• Wait for it to finish
• Open Settings
• Tap Privacy & Security
• Tap Analytics & Improvements
• Tap Analytics Data
• Scroll all the way to the bottom
• Find something called "sysdiagnose" and tap on it
• Tap the share icon in the upper right hand corner of the screen
• Save to Files
• Save to your iCloud Desktop folder

Then you can give the developer the file they need to diagnose the issue. Hope this helps!