I just saw the following in my work email:
- EMPLOYEE COMMS <EMPLOYEE-COMMS@XXXXXXXX>
- XXX Security Tip: The PDF Attachment Scam
- Thu, 2 Jun 2022 17:56:44 +0000
Please see attached XXX Security Tip information.
[Image file of the company logo and the following text: Thank you, Any questions, or concerns, Contact us: security@XXXXXXXX or (hotline) +1-XXXXXXXXXXXX]
“Security isn’t something you buy, it’s something you do, and it takes talented people to do it right.”
The attached document?
A PDF file.
This is a cool little video about the age old question: “Are Stormtroopers bad shots?” It also manages to answer the question “Are Ewoks that dangerous?” You might be surprised by the answer.
It's Sunday, and I go to check my email, only I can't. For some reason, the mouse isn't moving to the Linux screen. Odd. Perhaps Synergy crashed or something, so it's good thing I also have a KVM switch installed as well. Only the keyboard isn't working.
Swapping the keyboard connections on the KVM didn't work. Plugging in the keyboard cable for the Mac into the Linux system didn't work.
Okay, let's try rebooting. Only the machine didn't come back up.
Sunday had been bad enough. I decided not to think about the computer at all.
It was a rough few days and not without some panic. While I do have a backup of the files on the machine, it's a few months out of date, and the backup drive is a native Linux file system, so even if I had a current backup, I wouldn't be able to read it on the Mac (Important note: transfer some critical files to the Mac). And I run my own DNS server on the Linux box, so I had to work around that for a few days.
It turns out the computer is mostly fine—it's just the video card got fried somehow. And now I'm having to:
- set up a regular backup scheme;
- find a replacement video card;
- and get used to one screen in the meantime …
“Oh look! Someone sent you a quarter!”
“No, dear, that's a nickel.”
“Well, I guess that shows you how long it's been since I've seen a coin.”
“That wasn't so bad. I didn't hear you scream this time.”
“You wouldn't believe the advancements they've made in ball gags.”
I received the following email last night:
- Sergio Rios <XXXXXXXXXXXXXXXXXXXXX>
- Undisclosed recipients:;
- transfer done
- Fri, 17 Jun 2022 22:43:09 +0000
Trust you are having a good day. As earlier discussed in our last week meeting, your bitcoin wallet has been funded with 48 .99 BTC making a total of 1,433,296.04 USD. Please login with below details to confirm your BTC balance.
Website : XXXXXXXXXXXXXXXX
Customer ID : XXXXXXXX
I’ll be joining the team coming week for a symposium in Switzerland. Give me a call if anything else is needed.
I don't understand this email. It was sent to an email address I have that is the target of a lot of spam (it's the address I use for my domain registration and as I never opted to “hide” that email address, it's gotten around to a lot of spam lists), although the “undisclosed recipients” kind of gives it away as spam anyway. The website exists (I checked DNS) but I have not visited the site, so I don't know of the customer ID or password actually work. A quick web search on the domain name has revealed a lot of suspicion about the website, and a search on “Sergio Rios” doesn't reveal anything either.
So I have to wonder—what's the angle here? What's the scam? How is this supposed to work?
Firefox was giving me fits. It would work fine except when I quit the application, then it would just sit there consuming over 100% of the CPU (not hard given I have multiple CPUs on the machine). I even rebooted the machine on the off chance that Firefox thought it was running on a Windows box and not a Mac. But no, Firefox kept freezing when I quit the application.
I was afraid that somehow some critical file got corrupted and that I would have to nuke all my Firefox settings and start over again. But before I do that, let me just … maybe? clear the cache?
Yup. Clearing the cache fixed the issue. And upon thinking of it, I don't think I've bothered to clean the cache since … 2015? Really? It's been that long? Wow.
“Do you want to drive?”
“No thank you, I'd rather not drive to my doom.”
“It's not to your doom!”
“Okay, okay! I'd rather not drive to my mild annoyance.”
At The Enterprise, QA asked if they could have a tool that starts all our stuff up so they can do some performance tests (there are reasons they're asking for this, and why I agree with them that go beyond the scope of this entry). I replied I would see what I could do—it can't any harder than what I've done so far. And I came across an interesting bug.
The program will take our existing test cases, generate all the data and output a list of all the phone numbers so QA can use whatever they use to generate appropriate traffic. Then it will start up all the appropriate programs and just sit there, monitoring the processes such that if any stop, it stops the rest of them. And then QA can run whatever they run to inject requests into the maelstrom at whatever rate they see fit.
The bug in question: due to how the code was being written,
I was slowly moving code to catch two signals,
SIGINT (the interrupt signal) and
SIGCHLD (a child process has terminated) closer and closer to the start of the program
(for various reasons not germane to this entry).
At one point,
the program was always stopping because it thought one of the programs being tested has crashed when it hadn't.
I was able to isolate it—this code:
local tests = load_tests(arg) signal.catch('child') signal.catch('int')
signal.catch('child') signal.catch('int') local tests = load_tests(arg)
I then had a look at
load_tests() so see what in the world might be going on,
when I saw this:
os.execute("/bin/rm -rf dump/") -- other code local foo = io.popen("mkfoo lnp.dat","w") local bar = io.popen("mkbar sup.dat","w") -- other code
I was executing other programs to generate the data,
and those processes exiting were sending
SIGCHLD that the program
were not expecting.
Huh … leaking abstractions for the bugs!