The DMZ

forest

01:03

@belkarx It is good, but the unfortunate thing is that it causes Tails' copy of Tor Browser to stand out.

There are a lot of browser fingerprinting issues out there and of course not all can be mitigated, but Tails makes it way too easy to know that a given Tor Browser instance is running on Tails.

nobody

Maybe they should start including ublock in the main Tor browser too

forest

(ignore)

@nobody That would be nice. I believe the reason they don't do that is so they don't give websites even more reason to want to block Tor (i.e. Tor users never being able to see ads).

But to be honest, there's a lot that Tor Browser could do to improve...

The fact that it's effectively not hardened at all is a big thing that could change.

I mean, I get that JIT is enabled on the lowest security level (JS performance can be awful without it), but why do they still have to use such an insecure malloc as jemalloc? Supposedly their mozjemalloc is a little better than the stock thing and it won't have a huge impact on PresArena, but there are hardened allocators out there that can be added quite easily.

And there are a large number of fingerprinting issues that could be fixed if they put real effort into it (e.g. operating system fingerprinting using JS trig functions could be avoided if they didn't use the system math library, font fingerprinting could be reduced in scope if they didn't simply whitelist system fonts, etc.). Now, Tor itself is pretty damn good. It's just the browser that could use some work.

But 80% of the problem is just that they have to base it on Firefox ESR for practical reasons...

belkarx

02:02

@forest Brave supports Tor and is based on chromium, which comes with its own problems but at least they're different from those of firefox... also supposedly decent anti-fingerprinting is built in, not sure if its effectiveness has been independently verified though

forest

Brave is... very bad. Please don't use it.

belkarx

What makes you say it's bad

forest

It has a very small anonymity set and almost none of the custom anti-fingerprinting features Tor Browser has.

belkarx

Alright fair

forest

The "anti-fingerprinting" it has actually makes fingerprinting worse. Check on amiunique.org to see.

(I think that's the URL. Just got it from memory.)

It's like EFF's Panopticlick, but actually useful and not out of date and inaccurate (EFF's thing just exists to raise awareness of the problem of browser fingerprinting, but AmIUnique actually uses some pretty advanced techniques to test fingerprintability).

belkarx

02:05

@forest Their reasoning for the high "amiunique" rating was "yes your browser may be unique but it's differently unique across sites" which seemed reasonable, given it was actually done that way

forest

@belkarx That only confuses PoC websites. It doesn't hide many of the really unique details.

E.g. it probably doesn't do anything to resist font fingerprinting or CSS @media element fingerprinting at all.

belkarx

I see

forest

However because of its intentional randomization, it hides this fact because "you're unique [because of purposeful randomization]" is indistinguishable from "you're unique [in general]".

After all, stock Chrome with a random user agent generator extension would have the same effect, but obviously wouldn't be very good if you wanted to avoid being fingerprinted. In academic analyses of anonymity, blending in with the crowd is always the way to go (big anonymity set = good).

belkarx

@forest It really depends on how they implemented it then, maybe they did take most fingerprinting methods into account

forest

They didn't. It's extremely difficult (actually, nearly impossible) to do that.

From what I remember, they don't even implement the most basic mitigations.

belkarx

02:09

Ah unfortunate

forest

It took years for them to start working on AudioContext fingerprinting, and that only happened because upstream did it first.

belkarx

Okay so conclusion Brave sucks

forest

It sucks for anonymity. It might be good to avoid targeted advertising, but not anything else.

In the same way that a random VPN will protect you from the MPAA, but not a dedicated government agency.

belkarx

On the topic of fingerprinting, apparently Google scaled back its FloC idea ... techcrunch.com/2022/01/25/…. I wonder what the "privacy" implications are going to be if they transition to this (and how much profit they'd lose, as a whole, from not using cookies)

forest

Is that their stupid custom 3rd party cookie replacement?

belkarx

02:11

Yup

forest

(tbh I didn't look into it much, but I've heard only bad things about it)

And supercookies are a thing anyway.

belkarx

Exactly

forest

Privacy on the web is a lost battle for anyone using a regular browser without an anonymity network.

Especially now that IPv6 is making it practical to track people based on IP (not accurate before due to NAT / CG-NAT).

I was just looking through some of your answers, and came across:

3

A: Has there ever been a case of dangerous industrial malware, which would destroy motherboards and similar PC components and how to protect

Software-based malware can conceivably damage/wear down your hard drive/SSD by overusing it and overwriting it repetitively. You could, in the past, also seriously mess up your CPU/GPU configuration by playing with Windows registry keys (overclocking and such), so that is/was also a possible vect...

You know, one thing that might be possible but even more insidious than wearing an SSD is writing to NVRAM, which is usually flash based nowadays (old computers had it as battery-backed CMOS RAM). Rapid and continuous writes to /dev/nvram might very well brick a computer, at least if it's keeping important UEFI variables in NVRAM and not simply running in CSM mode.

It's something I've wanted to test for a while but kept putting it off.

It could be particularly dangerous because it could do damage to dedicated servers being rented in a practical amount of time, instead of trying to wear an easily-replaceable SSD which could take months or longer for modern, high-reliability flash technology.

belkarx

02:30

@forest Overwriting NVRAM is actually quite an interesting idea, and much more practical than corrupting the SSD. If you do try it, update me because it seems like a great attack vector

forest

Will do. I'll post the results here if I do it.

But currently I'm thinking of trying to brick a Nintendo DS in hardware instead by disabling the LCD driver outside of H-blank. :)

belkarx

Though if it's only used for caching (as opposed to exclusive storage of important data), it's not necessarily vital and normal SRAM? can fill in

forest

@belkarx It's used by the BIOS. Very important in UEFI mode.

And only 144 bytes of storage (usually).

belkarx

Ah alr, I'll need to look into it more

forest

wiki.osdev.org/UEFI_NVRAM and elixir.bootlin.com/linux/latest/source/drivers/char/nvram.c

belkarx

02:33

thanks :)

forest

Probably a lot of information in some sort of Coreboot or uh... what's that open source UEFI framework called?

TianoCore, that's it.

belkarx

I'll check them out

Would having Secure Boot enabled affect ability to write to firmware-y memory

ie CMOS chip

forest

I doubt it. Secure Boot is very limited in what it can do (and tbh I know close to nothing about it. I far prefer SRTM).

belkarx

Imo secure boot is largely an inconvenience and quite a few malware families have bypassed it in the past. What does SRTM stand for?

forest

I think Secure Boot only affects code to be executed.

SRTM = Static Root of Trust for Measurement.

belkarx

02:37

Ah

forest

It's the most basic thing a TPM can do to ensure the state of a computer's TCB.

Essentially, the CRTM (Core Root of Trust for Measurement) aka BIOS boot block is a read-only portion of the BIOS which simply passes a hash of the BIOS to the TPM which stores it in PCRs. Then the PCRs are extended as the next hash is added (for PCI option ROMs, other firmware config stuff, MBR, bootloater, etc.). Then the TPM can "unseal" if the hash at the end matches a desired value. The unsealed content is what proves the computer has not been tampered with. See Qubes' Anti-Evil Maid.

2

belkarx

Where did you learn about booting at such a low level?

forest

OSDev wikis, forums, datasheets, and lots of reading.

Also CHIPSEC. But I really don't know all that much. Not as much as I want, at least.

And STARK/MARK and TreVisor are great research projects.

faui1-files.cs.fau.de/filepool/projects/mark/index.html for MARK. And trmm.net/Heads (Heads) is cool too.

belkarx

Yup I was intrigued by TreVisor, but it's a classic example of security by obscurity

forest

No it's not.

It uses TRESOR and BitVisor to provide mutual authentication.

Without access to the auth hardware and credentials, you can't unlock the system. And without arbitrary code exec, you can't extract the AES key for the disk, even if you do a cold boot attack.

Knowledge that the AES key resides in the debug registers doesn't help you get them any easier. :P

belkarx

02:43

You can dump the encryption keys if you have access to the machine, though i suppose that's an unlikely scenario. I still feel like it could be improved

forest

Not with TRESOR, since the keys are stored nowhere in memory.

Of course, if you use JTAG or otherwise compromise it to exec your own code in ring 0 you can, but you can't just dump memory.

belkarx

Is that what it's mainly intended to protect against?

... I need to go reread the paper

forest

That's what TRESOR is designed to protect against, and that alone. It doesn't even encrypt the page cache (although RamCrypt does, but it's REALLY slow). Of course there are still some easy-to-solve problems (it is a research PoC after all), like GPRs containing key material during encryption being pushed to the stack if an NMI or SMI occurs (regular interrupts are disabled during enc/dec operations).

belkarx

I see

forest

It's probably better just to use a newer CPU that supports hardware memory encryption though. TRESOR may still be useful, but since it doesn't encrypt the page cache or anything other than the AES key itself, it's far from perfect, but it can still prevent an encrypted disk from being decrypted. Also, using TRESOR correctly requires a (basic) understanding of cryptography. You can use aes-cbc-plain, but not aes-cbc-essiv or aes-xts-plain. So it may be a good idea to cascade it with aes-xts.

You could probably get it to work without being too malleable without another layer of encryption if you change the XTS driver to instead use XEX, since then you can re-use the 256-bit key for both the master key and the tweak (and dm-crypt doesn't use ciphertext stealing).

(XTS = XEX but with a separate key and tweak, and ciphertext stealing which isn't necessary on a block device)

TreVisor does that all automatically btw. I think it actually does use XEX in the way I described, and because it's a hypervisor, it transparently does it for any connected block device. It's just a research project though, and it reduces security in some areas (I think BitVisor, which TreVisor is based on, doesn't support DMAR, so DMA attacks might be possible against non-hypervisor memory?)

Btw, none of this does anything to protect from cold boot attacks against GPU VRAM. :P

belkarx

02:56

Eh no such thing as perfect security

@forest is there any currently available way to guard against that?

forest

You can wipe VRAM on shutdown in a couple ways I suppose, but otherwise, not really.

belkarx

What can you really do with access to GPU VRAM anyway though

forest

Of course VRAM won't contain your encryption key (unless you've displayed it in your framebuffer or did some sort of GPU operations on it for some silly reason), but it certainly contains a lot of stuff that you've displayed in the present and past.

@belkarx hsmr.cc/palinopsia

(for example)

> Mitigation

If you use you computer to access sensitive data, TURN IT OFF after usage, so VRAM is disconnected from power.
Be wary of virtual machines with access to hardware accelerated graphics.

And those images aren't even close to the limit of what can be done. They're just showing what happens when you try to use "unallocated" memory for graphics. Accessing VRAM directly by messing with PCI BARs would let you see everything.

(Some discussion from Tails' bug tracker about this problem: gitlab.tails.boum.org/tails/tails/-/issues/5356)

belkarx

@forest Alright the amount of data that gets kept is kinda scary

forest

@belkarx Well, it'll all be gone after several seconds of no power. GPUs use DRAM after all.

belkarx

03:03

I mean that's the case with most cold boot attacks but they are still concerning (given you're at enough risk to care, otherwise they're just interesting)

forest

Cold boots are easier to exploit now that they're so well-known and so much work by law enforcement has gone into making it feasible. It's been done in practice by adversaries not nearly as sophisticated as the NSA.

That's why hardware-based memory encryption like AMD's thing is such a good idea.

belkarx

What are the chances it's backdoored though

forest

Probably pretty low. But the chances that the implementation is broken? Who knows.

I'd wager that it's secure enough though. But physical access can still allow an attacker to attempt other hardware attacks which may succeed. Motherboard traces are not traditionally considered to be untrusted inputs. :)

belkarx

Yup there are so many possible side channel attacks that guarding against all of them while still having a usable computer is impossible

forest

But it'd still protect against someone who can only remove RAM modules or modify firmware and force the system to reset (as in that case in the Netherlands where the BIOS was modified to dump memory over serial and the system was then forced to reset).

@belkarx And fault injection attacks!

Don't neglect the more invasive procedures if your adversary is physical.

Tbh most of this is academic for COTS desktop computers. Physical access is usually game over. I'd be far more worried about a kernel exploit (think: EDID parser vulnerabilities or so) than most low-level hardware issues that require physical access.

nobody

05:44

11

Q: Isn't "BIOS reset password" a security flaw?

According to this article Dell Support can help a user to gain access to data after forgetting the HDD password: Once Dell Support has provided the reset password, you enter this when prompted and then press Ctrl + Enter to complete the process. ... the BIOS should accept the reset password, cle...

Which one is the correct answer here?

MechMK1

14:00

-2

Q: what does a day look like for a professional in infosec?

I would love to hear from you what business in this industry looks like on a corporate level. What is your job title, what are your daily tasks, and are you satisfied with your income?

career

What is this edit history?

Fire Quacker

Somebody was embarrassed about their (deleted) question and wanted to hide all traces of it?

MechMK1

In terms of deleted questions, it's not even bad

It's "Not suitable for SE but not a bad question per se" tier

Aka. you're better off asking on the DMZ

I think the worst "question" was like "Is my neighbor spying on me with a camera?" and it was just an Ikea lamp on a desk

2

ThoriumBR

I was reading about the dirty pipe vuln, and found something interesting: it can "write" to any file, even immutable files, or files on a CD-ROM... it does this by changing the file on the page cache, so the cached version is altered even if the disk version is on ROM.

and kernel will use the cached version

MechMK1

@ThoriumBR What privs do you need for that to work?

ThoriumBR

I am wondering if it works if the fs is mounted with xip flag (execute in place)... I used XIP some time ago when we mounted a shared ramdisk over several guests

@MechMK1 basically you need read access on the file

if you can execute anything on your home, you can change /etc/passwd and give you UID 0

MechMK1

14:10

Hmmm...so you can't just change /etc/shadow

ThoriumBR

nope, but it's not needed... replace root:x:0:0:root:/root:/bin/bash with root::0:0:root:/root:/bin/bash, done. passwordless root

bash isn't suid? no problem, bash is now suid root.

MechMK1

Got a link where I can read up on it?

I wanna try this in a VM

ThoriumBR

redhuntlabs.com/blog/the-dirty-pipe-vulnerability.html

dirtypipe.cm4all.com

"This is the story of CVE-2022-0847, a vulnerability in the Linux kernel since 5.8 which allows overwriting data in arbitrary read-only files. This leads to privilege escalation because unprivileged processes can inject code into root processes."

MechMK1

"I spent all evening doing a dirty pipe"
"I didn't know you had a girlfriend?"
"Huh?"
"Huh?"

Unrelated, but Red Bull Açaí tastes weird as fuck

ThoriumBR

you forgot the "penetration testing" on your evening report...

Red Bull Açaí? interesting... I am not a fan of Red Bull, but açaí is tasty

my wife says it tastes like dirt, but I like it

MechMK1

14:16

"So, tell me about yourself?"
"I'm a professional penetrator. Like, I get in there deep, really deep"
"Oh my...how deep are we talking?"
"DA in 3 hours"

nobody

21:10

4

A: Periodic outages again?

We were hit by a DDoS attack. While the attack itself was mitigated by our systems, the conditions set off a series of errors that managed to uncover an edge case in one of our backend systems. It took several hours for us to identify the issue because the errors only manifested themselves once a...

Fire Quacker

21:45

It is so surprising how many places you have to censor the word *nix to get past the word filters. Microsoft has so much control over the Internet...

forest

22:23

@ThoriumBR It'll work with XIP.

I'm pretty sure XIP doesn't bypass the page cache for files opened RO and read from.

Basically, if reading from a file will populate page tables, then a vulnerability which dirties those page tables (even if it doesn't mark them as dirty) will work. All an XIP filesystem will guarantee is that executing the file will bypass the page cache. But I'm not 100% sure since I haven't used any FS that supports XIP before.

ThoriumBR

23:03

ext*2* supports XIP

but I don't have any vulnerable kernel around to test... maybe I will spin up something to test.

IIRC, XIP does bypass the page cache, that's the main reason for XIP to exist.

the case for XIP: you have 2000 guests under the same hipervisor, and all of them load the same RHEL 8.5 version, all libs, everything is the same. So you create a ramdisk, put /usr and /lib there, and share that ramdisk inside the memory space of all guests. If you mount the fs as XIP, you can run straight from it without needing cache, and you save a lot of memory. 2000 guests saving 500MB of memory each because data is already loaded will save you 1TB of memory.

sadly I cannot find any documentation right now, all my bookmarks got invalidated because IBM changed the documentation site.

and it's time to feed the kids and put them to bed

forest

@ThoriumBR Yeah it does, but I was under the impression it was only when executing.

@FireQuacker It's actually AT&T that's responsible for calling it *nix. The reason is that UNIX is a registered trademark.

The use of the censorship/wildcard is now obsolete ever since The Open Group got ownership of the trademark, but it's still common to refer to UNIX and UNIX-like or derived systems. So *nix means UNIX proper, Linux, the BSDs, etc.

70

Q: What is the meaning of *nix?

What is the meaning of *nix, and what is its relation with Ruby? Just saw that in an interview question... I think there is something to do with UNIX distros, but I am not sure. Could not find it here or in the Wikipedia, so I am asking. What is the meaning ? And what is its relation with Rub...

ruby linux unix operating-system

ThoriumBR

23:30

@nobody I never saw a "whitepaper" so literal...

Transcript for