Ham Radio May Speed Up Soon

The FCC is circulating a proposal for new rules pertaining to amateur radio in the United States. In particular, they want to remove certain baud rate restrictions that have been in place since 1980. It appears the relaxed rules would apply only to some bands, notably some VHF and UHF bands along with the 630 meter and 2200 meter bands, which — we think — are lightly used so far. We’ll save you from grabbing the calculator. That’s around 475 kHz and 136 kHz.

Ham radio operators have long used digital modes like radio teletype and with restrictions on antennas and increasing interference from wireless networking to solar panels and more, digital has become even more popular than in the past. Besides that, cheap computer soundcards make it easier than ever and sophisticated digital modulation techniques have long left the old, clunky TeleType in the dust.

However, the FCC currently limits the baud rate to 300 baud or less, ostensibly to restrict signal bandwidth. No one wants to have an entire band consumed by a 10 Gb RF network. However, modern techniques often squeeze more into less and the FCC will finally recognize that by converting the limit to signal bandwidth, not baud rate.

What’s the bandwidth? For the common bands, it sounds like 2.8 kHz is the answer. For the VLF bands, they are asking for suggestions. The 2200 meter band isn’t even 2.8 kHz wide to start with!

All this talk makes us want to build something for the 2200 meter band. We better start winding the coil now. Then again, maybe we should go piezo. You know, just in case Thomas Dolby tells us that one of our submarines is missing.

This Week In Security: 1Password, Polyglots, And Roundcube

This week we got news of a security incident at 1Password, and we’re certain we aren’t the only ones hoping it’s not a repeat of what happened at LastPass. 1Password has released a PDF report on the incident, and while there are a few potentially worrying details, put into context it doesn’t look too bad.

The first sign that something might be amiss was an email from Okta on September 29th — a report of the current list of account administrators. Okta provides authentication and Single Sign-On (SSO) capabilities, and 1Password uses those services to manage user accounts and authentication. The fact that this report was generated without anyone from 1Password requesting it was a sign of potential problems.

And here’s the point where a 1Password employee was paying attention and saved the day, by alerting the security team to the unrequested report. That employee had been working with Okta support, and sent a browser session snapshot for Okta to troubleshoot. That data includes session cookies, and it was determined that someone unauthorized managed to access the snapshot and hijack the session, Firesheep style.

Okta logs seemed to indicate that the snapshot hadn’t been accessed, and there weren’t any records of other Okta customers being breached in this way. This pointed at the employee laptop. The report states that it has been taken offline, which is good. Any time you suspect malicious action on a company machine, the right answer is power it off right away, and start the investigation.

And here’s the one part of the story that gives some pause. Someone from 1Password responded to the possible incident by scanning the laptop with the free edition of Malwarebytes. Now don’t get us wrong, Malwarebytes is a great product for finding and cleaning the sort of garden-variety malware we tend to find on family members’ computers. The on-demand scanning of Malwarebytes free just isn’t designed for detecting bespoke malicious tools like a password management company should expect to be faced with.

But that turns out to be a bit of a moot point, as the real root cause was a compromised account in the Okta customer support system, as revealed on the 20th. The Okta report talks about stolen credentials, which raises a real question about why Okta support accounts aren’t all using two-factor authentication.

Continue reading “This Week In Security: 1Password, Polyglots, And Roundcube”

2023 Hackaday Supercon: Cory Doctorow Signs On As Keynote Speaker

As if you weren’t already excited enough about the speakers and events that will be part of this year’s Hackaday Supercon, today we can finally reveal that journalist, activist, author, technologist, and all around geek Cory Doctorow will be presenting the keynote address on Saturday morning.

Cory has always been an outspoken supporter of digital freedom, from helping develop OpenCola in 2001 as a way to explain the concepts behind free and open source software, to his more recent work at the Electronic Frontier Foundation. He’s made his novels available for purchase directly from his personal website in DRM-free file formats, and he’s even developed a habit of releasing some of them for free under the Creative Commons license. The hacker ethos is strong with this one.

Over the last year, he’s been particularly vocal about what he calls Enshittification — the inevitable decay of any online service where the users are, whether they realize it or not, the product. It’s a concept that’s perfectly exemplified by the ongoing slow-motion implosion of Twitter, and Reddit’s increasingly hostile treatment of its community. Cory explains that one of the signposts on this particular journey is when user-created tools, such as web scrapers or bots, are banned by the powers that be. Reverse engineering, especially when it can uncover a way out of the Walled Garden, is strictly forbidden.

Luckily, there’s a way out. Cory will be delivering his talk An Audacious Plan to Halt the Internet’s Enshittification and Throw It Into Reverse, not only to those who will be physically attending Supercon, but to the entire Hackaday community via our live YouTube stream of the event. It’s a presentation that’s critically important to an audience such as ours — while nearly anyone with an Internet connection can appreciate the problem he’s describing, hackers and makers are in a unique position to actually do something about it. Following the principles Cory will detail in his talk, we can build services and networks that actually respect their users rather than treating them like the enemy.

It Won’t Be Long Now

By the time this post hits the front page of Hackaday, there will be slightly more than a week to go before several hundred of our best friends descend on the city of Pasadena for Supercon. We recently unveiled the Vectorscope badge, dropped two posts listing off all of this year’s presenters, and offered up a list of fascinating workshops. The stage is now officially set for what we consider, as humbly as possible, to be the greatest gathering of hardware hackers, builders, engineers, and enthusiasts in the world. Check out the schedule and plan your Supercon ahead of time.

Tickets for the 2023 Hackaday Supercon are, perhaps unsurprisingly, completely sold out. But you can still add your name to the wait list on Eventbrite, which will put you in the running to grab any returned tickets should somebody have to back out at the last minute. Failing that, there’s always 2024.


Featured Image: Copyright Julia Galdo and Cody Cloud (JUCO), www.jucophoto.com/, CC BY-SA 2.0

2023 Hackaday Supercon: The Rest Of The Talks

The 2023 Hackaday Superconference is only two weeks away, and we’re happy to announce the second half of the slate. As always, this is a great mix of well-known Hackaday faces, and folks we haven’t yet met. Whether they’re fixing up the Apollo Guidance Computer, building their own airplanes, trapping rubidium atoms, or teaching robots to sail, this is another super interesting round of talks.

Tickets are sold out, the badges are almost done, and we’re in the home stretch! We can smell the tacos from here. If you’re joining us, we hope you’re excited. If you’re not able to, we’ll stream as much as we can.

All that remains is the mystery of the keynote speaker.  Stay tuned! Continue reading “2023 Hackaday Supercon: The Rest Of The Talks”

Daily Inspections Keep Your Spitfire In Tip-Top Shape

What ho, chaps? Look, we know this is a bally nuisance and all, but those desk jockeys at HQ want us all to watch this film about daily insepction of your Spitfire. No Vera and no Greta in this one, more’s the pity, but it is jolly important. We all know that our Spitfires are complicated buckets of bolts, but those kites won’t stay in the air if we don’t maintain them. Yes, the boring stuff, like purging the fuel system of water and refueling outside of the hanger. And, yes, Captain Molesworth, that means putting out that cigar while the tech boys are topping off your tank. Now shut up and watch the film we’ve placed below the break, what?

All right, all right, wake up at the back there. I heard you snoring, Peason. The bally Germans could hear you snoring. I know that wasn’t Errol Flynn, but this stuff is damned essential. You may be pilots, but you all rely on those people you just saw. Your lives depend on the riggers, armorers, instrument repairers, and others. While you are out carousing, these men are taking your plane apart and ensuring the engine is running smoother than the legs of the barmaid at the Dog & Duck. Every time one of you chaps calls Bingo Fuel, you get home because some chap checked your fuel gauge was accurate. Every time one of you glances at the Rate of Climb indicator to judge an intercept, you are relying on the chap who tested and zeroed it while you were snoring in your bunk, sleeping off last nights debauch. So, don’t forget that you are part of a team. You may be full of dauntless spirit  up there, but you won’t get anywhere without those chaps on the ground.

Now, let’s talk about tonight’s mission…

Continue reading “Daily Inspections Keep Your Spitfire In Tip-Top Shape”

National Research Council laboratories in Ottawa

Canada Abruptly Ends Official Time Signal

In a sudden move that was noted not only by Canadian media, but also international media channels, the National Research Council Time Signal that was broadcast by Canadian Broadcasting Corporation (CBC) on CBC Radio One since November 5 1939 was turned off on October 9th, after eighty-four years, one world war, countless generations, and the rise of modern technology. Although perhaps obsolete by today’s standards, this 15 to 60 second long broadcast at 13:00 Eastern Time every single day has been a constant in the life of Canadians, whether they tuned into local radio, or (increasingly) via Internet radio.

The NRC Time Signal consisted out of a series of 800 Hz sinewave ‘beeps’ followed by a second-long signal to indicate the top of the hour. Back in the day this was extremely useful to sync one’s clocks, watches and other time-keeping devices to. Yet between the transmission delays caused by Internet radio and the increased availability of NTP and other time sources on modern-day devices, the signal’s main use appears to have become a nostalgic reminder of what once was a constant of each and every day.

In this regard the public response to the rather unceremonious decommissioning without prior announcement was rather predictable. After all, even if it wasn’t that useful, why throw out something that is more recognizable than any other radio jingle for generations of Canadians?

Top image: National Research Council laboratories in Ottawa.

This Week In Security: Curl Reveal, Rapid Reset DDoS, And Libcue

Curl gave us all a big warning that a severe security problem had been found in that code-base. Given the staggering number of Curl installs around the world, we held our collective breath and waited for the bombshell to drop this Wednesday. It turns out, it’s not quite as bad as feared — so long as you don’t have a SOCKS proxy.

In hindsight, shipping a heap overflow in code installed in over twenty billion instances is not an experience I would recommend. — Daniel Stenberg

The trouble started when the SOCKS5 proxy support was converted to a non-blocking implementation. It’s a win for libcurl to work on requests asynchronously, but refactoring code and new features always runs a bit of risk. SOCKS5 proxying has some quirks, like allowing DNS resolution to happen locally or at the proxy. The new async code starts out with:

bool socks5_resolve_local =
(proxytype == CURLPROXY_SOCKS5) ? TRUE : FALSE;

First off, unnecessary ternary is unnecessary. But note that this local variable gets set by the proxytype. If that’s CURLPROXY_SOCKS5_HOSTNAME, then it uses remote resolution. But inherited from old code is a check for a hostname that is too long for a SOCKS request (255 bytes). This code converts back to local resolution in this case.

The important detail here is that this function is now a state machine, that potentially runs multiple times for a single request, to achieve that asynchronous execution. The check for a too-long hostname only happens during the initialization state. Copying the hostname into the buffer happens in a different state. If setting up the connection takes enough time, the function will return and be executed again when something has changed. The ternary check runs again, but not the hostname-too-long. So if set to do remote resolution with a long enough host name, execution slips through this edge case, and the long hostname is copied into a too-small buffer.

It’s safe to assume that this heap overflow can result in arbitrary code execution. The fix has landed in 8.4.0, after being present for 1,315 days. [Daniel] goes ahead and gets ahead of the inevitable suggestion that Curl should be written in rust or another memory-safe language. Curl was started before those alternatives existed, and there is a very slow effort to move portions of the project to memory-safe languages. And you’re welcome to help out. Continue reading “This Week In Security: Curl Reveal, Rapid Reset DDoS, And Libcue”