scarybeast

@tptacek -- you're so awesome. I keep meaning to reply on some of these security threads but then I see you've made the relevant points of sanity in a well reasoned manner.

For what it's worth, when I was setting up the culture and values of Google's first bug bounty programs, I hammered "be magnanimous" into the reward committees. i.e. look for reasons to reward more, not less. Find the value in the information provided, even if the person is being a jerk. etc. I don't think this culture has changed. There are teams of people rooting for incoming reports to succeed, and they get excitement and joy from issuing large bounties (because this means Google security is getting stronger).

The floppy disc controller doesn't have a way of knowing if the write worked or not. There are some corner cases here, like the drive can signal a fault line if it's on fire, but if there's simply a dodgy patch of disc surface, nothing will be apparent during the write.

So, the operating system could verify the write by reading it back, but I don't think the BBC Micro disc ROMs typically did that for file writes -- only for formats.

Do you have any recommendations for any particular techniques or software? I'd gladly try them.

Great that you're working on something similar! How are you finding those tools for handling degraded tape waveforms? I keep bouncing back and forth between hacking up my own vs. wanting to find some existing tool that has some clever math formula.

The blog post uses conventions associated with the machine in question, the BBC Micro, which is an iconic 1980s UK machine. It was pretty much "Disc" back then, e.g. the dreaded "Disc error 0E" from the OS, or the spelling written on the discs themselves, e.g. this Watford Electronics Diagnostics disc:

http://www.computinghistory.org.uk/det/21293/Diagnostics-Dis...

Not sure if it's a UK thing or a 1980s thing.

I'd personally phrase things a bit differently: an _individual_ was able to pull this off while surrounded by screaming children. A large government, with all its resources and hundreds+ of people, would pull this off regularly and without breaking a sweat.

We definitely wanted fun! I guess there are two ways to slice and dice it: 1) fun because the application is exotic / iconic, or 2) fun because the chip is exotic. This is definitely a case of the latter: an exotic chip with interesting history.

I think this is a bad decision. The "in-the-wild" part is the interesting part because it is not the norm at all and it implies an interesting story.

These are some good hacks and tricks! The good news is that these fun days are still upon us. I'm a member of the Bitshifters collective: https://bitshifters.github.io/

For example, the most recent demo led by VectorEyes, called Evil Influences, breaks new ground in BBC Micro video chip chicanery: https://bitshifters.github.io/posts/prods/bs-evil-influences...

Direct link to the video: https://www.youtube.com/watch?v=HvjhKY67fPI

That's an interesting story of the 6522 VIA for sure :) I don't think it is what I was hitting though, for a few reasons:

1) "The 6522 has a bug in mode 011, shifting synchronous serial data in under control of external CB1 clock" -- this is not the mode I tried.

2) The bug appears to be intermittent data loss. What I had trouble with seemed deterministic, the chip is just too slow to respond.

3) I wonder if this hardware bug was ever fixed? The BBC Micro doesn't use the MOS 6522 VIA. It tends to use Synertek or Rockwell. It's unclear if those companies were just using the buggy MOS mask under licence, or something else.

I've also been referred to this which definitely belongs here. It's a write up of fairly advanced weak bits usage on the 1984 Apple II educational title "Kingdom of Facts".

https://ia800600.us.archive.org/2/items/TheKingdomOfFacts4am...

Interesting, I didn't know the Apple II's controller could write the combined data and clock bits. That's unfair :) I was also pointed to this Twitter thread where it is explained that they wrote Mr. Do weak bits with a hacked up Commodore 64 drive controlled by an Apple II!

https://twitter.com/JBrooksBSI/status/936476972611334147

I like the framing here, that of seeing this as a showcase of modern superscalar improvements. And yes, it's about single core performance only.

What is particularly interesting to me is how thoroughly superscalar "wins". Because of complexities with 6502 -> x64 mapping, and handling self-modifying code in particular, some of the most common 6502 instructions explode to multiple x64 instructions. Despite that huge extra instruction load, the translation still manages to run at much greater speed than a 1:1 instruction ratio.

Modern processors do not run on electrons. They run on unicorn tears and magic.

I was wondering about this. Does LLVM offer facilities expressive enough to model things like self-modification and arbitrary interruptability?

I agree it'd be wonderful to see auto-vectorization! Obviously, 6502 code does things 1 byte at a time so even adding 32-bit integers is painful. Auto-upgrade of those loops to 32-bit variants would be amazing.

A lot of BBC BASIC programs, doing real work (e.g. Mandelbrot drawing etc.), should have a shot at 10GHz. Games are slower because they are hammering hardware registers external to the JIT (sound, graphics, keyboard polling, timing, etc.)

My laptop is an ancient 5th gen i5 with 2 keys having fallen off, so games are down in the 2GHz - 3GHz range for me. (Perhaps the missing keys make all the difference.)

FWIW, I've been very impressed with how Yahoo! handled this disclosure.

This is YB (Yahoobleed) #2. You might also enjoy YB #1: "*bleed continues: 18 byte file, $14k bounty, for leaking private Yahoo! Mail images": https://scarybeastsecurity.blogspot.com/2017/05/bleed-contin...

This is true. But in the case where the malloc heap metadata is under attack, the attacker will usually just allocate exactly the right size to ensure that the off-by-one goes off the end of the chunk, instead of into slack space.

Yeah, good question.

The lower bits of ->size are actually masked off when considering a chunk's size, because they are flags:

#define SIZE_BITS (PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)

/* Get size, ignoring use bits */ #define chunksize(p) ((p)->size & ~(SIZE_BITS))

So you really can't increase the size by less than 8. However, I know what you're now thinking: an attacker with a 1-byte overflow can mess with the flags! That would be a topic for another blog post, but I'm not aware of any techniques where messing with the flags would permit a clean ASLR bypass.