News

3617 Articles

Dexter Robot Arm Embraces New Manufacturing With First Micro-Factory

March 9, 2020 by 32 Comments

Haddington Dynamics, the company behind the Dexter robot arm that won the 2018 Hackaday Prize, has opened its first microfactory to build robot arms for Australia and Southeast Asia.

You may remember that the combination of Dexter’s makeup and capabilities are what let it stand out among robotics projects. The fully-articulated robot arm can be motion trained; it records how you move the arm and can play back with high precision rather than needing to be taught with code. The high-precision is thanks to a clever encoder makeup that leverages the power of FPGAs to amplify the granularity of its optical encodes. And it embraces advanced manufacturing to combine 3D printed and glue-up parts with mass produced gears, belts,  bearings, and motors.

It’s a versatile robot arm, for a fraction of the cost of what came before it, with immense potential for customization. And did I mention that it’s open source? Continue reading “Dexter Robot Arm Embraces New Manufacturing With First Micro-Factory” →

John Deere And Nebraska’s Right To Repair, The Aftermath Of A Failed Piece Of Legislation

March 9, 2020 by 99 Comments

For the past few years now we’ve covered a long-running battle between American farmers and the manufacturers of their farm machinery, over their right to repair, with particular focus on the agricultural giant John Deere. The manufacturer of the familiar green and yellow machinery that lies in the heart and soul of American farming has attracted criticism for using restrictive DRM and closed-source embedded software to lock down the repair of its products into the hands of its dealer network.

This has been a hot-button issue in our community as it has with the farmers for years, but it’s failed to receive much traction in the wider world. It’s very encouraging then to see some mainstream coverage from Bloomberg Businessweek on the subject, in which they follow the latest in the saga of the Nebraska farmers’ quest for a right to repair bill. Particularly handy for readers wishing to digest it while doing something else, they’ve also recorded it as an easy-to-listen podcast.

We last visited the Nebraska farmers a couple of years ago when they were working towards the bill reaching their legislature. The Bloomberg piece brings the saga up to date, with the Nebraska Farm Bureau failing to advance it, and the consequent anger from the farmers themselves. It’s interesting in its laying bare the arguments of the manufacturer, also for its looking at the hidden aspect of the value of the data collected by these connected machines.

It’s likely that the wider hardware hacker community and the farming community have different outlooks on many fronts, but in our shared readiness to dive in and fix things and now in our concern over right to repair we have a common purpose. Watching these stories at a distance, from the agricultural heartland of the European country where this is being written, it’s striking how much the farmers featured are the quintessential salt-of-the-earth Americans representing what much of America still likes to believe that it is at heart. If a company such as John Deere has lost those guys, something really must have gone wrong in the world of green and yellow machinery.

Header image: Nheyob / CC BY-SA 4.0

The Legacy Of One Of Science’s Brightest Stars: Freeman Dyson

March 9, 2020 by 8 Comments

Of the many well-known names in science, few have been as reluctant to stick to one particular field as Freeman John Dyson. Born in the UK in 1923, he showed a great interest in mathematics and related fields even as a child. By the time he was 15 he had won a scholarship at Trinity College, in Cambridge, where he studied mathematics. Though the war forced him to work at the Air Force’s Operational Research Section (ORS), afterwards he would return to Trinity to get his BA in mathematics.

His subsequent career saw him teaching at universities in the UK and US, before eventually ending up at Cornell University, where he joined the Institute for Advanced Study at the invitation of its head, J. Robert Oppenheimer. Here he would meet up with such people as Richard Feynman with whom he would work on quantum electrodynamics.

Beyond mathematics and physics, Dyson would also express great interest in space exploration — with Dyson spheres being well-known — and genetics, both in the context of the first formation of life and in genetic manipulation to improve plants to deal with issues today. He also worked on the famous Project Orion, which used nuclear bombs for propulsion.

In this article we’ll take a look at these and other parts of Mr. Dyson’s legacy, as well as the influence of his works today.

Continue reading “The Legacy Of One Of Science’s Brightest Stars: Freeman Dyson” →

This Week In Security: Let’s Encrypt Revocation, Ghostcat, And The RIDLer

March 6, 2020 by 7 Comments

Let’s Encrypt recently celebrated their one billionth certificate. That’s over 190 million websites currently secured, and thirteen full-time staff. The annual budget for Lets Encrypt is an eye-watering $3.3+ million, covered by sponsors like Mozilla, Google, Facebook, and the EFF.

A cynic might ask if we need to rewind the counter by the three million certificates Let’s Encrypt recently announced they are revoking as a result of a temporary security bug. That bug was in the handling of the Certificate Authority Authorization (CAA) security extension. CAA is a recent addition to the X.509 standard. A domain owner opts in by setting a CAA field in their DNS records, specifying a particular CA that is authorized to issue certificates for their domain. It’s absolutely required that when a CA issues a new certificate, it checks for a CAA record, and must refuse to issue the certificate if a different authority is listed in the CAA record.

The CAA specification specifies eight hours as the maximum time to cache the CAA check. Let’s Encrypt uses a similar automated process to determine domain ownership, and considers those results to be valid for 30 days. There is a corner case where the Let’s Encrypt validation is still valid, but the CAA check needs to be re-performed. For certificates that cover multiple domains, that check would need to be performed for each domain before the certificate can be issued. Rather validating each domain’s CAA record, the Let’s Encrypt validation system was checking one of those domain names multiple times. The problem was caught and fixed on the 28th.

The original announcement gave administrators 36 hours to manually renew their affected certificates. While just over half of the three million target certificates have been revoked, an additional grace period has been extended for the over a million certs that are still in use. Just to be clear, there aren’t over a million bad certificates in the wild, and in fact, only 445 certificates were minted that should have been prevented by a proper CAA check.

Ghostcat

Apache Tomcat, the open source Java-based HTTP server, has had a vulnerability for something like 13 years. AJP, the Apache JServ Protocol, is a binary protocol designed for server-to-server communication. An example use case would be an Apache HTTP server running on the same host as Tomcat. Apache would serve static files, and use AJP to proxy dynamic requests to the Tomcat server.

Ghostcat, CVE-2020-1938, is essentially a default configuration issue. AJP was never designed to be exposed to untrusted clients, but the default Tomcat configuration enables the AJP connector and binds it to all interfaces. An attacker can craft an AJP request that allows them to read the raw contents of webapp files. This means database credentials, configuration files, and more. If the application is configured to allow file uploads, and that upload location is in the folder accessible to the attacker, the result is a full remote code execution exploit chain for any attacker.

The official recommendation is to disable AJP if you’re not using it, or bind it to localhost if you must use it. At this point, it’s negligence to leave ports exposed to the internet that aren’t being used.

Have I Been P0wned

You may remember our coverage of [Troy Hunt] over at haveibeenpwned.com. He had made the decision to sell HIBP, as a result of the strain of running the project solo for years. In a recent blog post, [Troy] reveals the one thing more exhausting that running HIBP: trying to sell it. After a potential buyer was chosen, and the deal was nearly sealed, the potential buyer went through a restructuring. At the end of the day, the purchase no longer made sense for either party, and they both walked away, leaving HIBP independent. It sounds like the process was stressful enough that HIBP will remain a independent entity for the foreseeable future.

You Were Warned

Remember the Microsoft Exchange vulnerability from last week? Attack tools have been written, and the internet-wide scans have begun.

Ridl Me This, Chrome

We’ve seen an abundance of speculative execution vulnerabilities over the last couple of years. While these problems are technically interesting, there has been a bit of a shortage of real-world attacks that leverage those vulnerabilities. Well, thanks to a post over at Google’s Project Zero, that dearth has come to an end. This attack is a sandbox escape, meaning it requires a vulnerability in the Chrome JS engine to be able to pull it off.

To understand how Ridl plays into this picture, we have to talk about how the Chrome sandbox works. Each renderer thread runs with essentially zero system privileges, and sends requests through Mojo, an inter-process communication system. Mojo uses a 128 bit numbering system to both identify and secure those IPC endpoints.

Once an attacker has taken over the unprivileged sandbox process, the next step is to figure out the port name of an un-sandboxed Mojo port. The trick is to get that privileged process to access its Mojo port name repeatedly, and then capture an access using Ridl. Once the port is known, the attacker has essentially escaped the sandbox.

The whole read is interesting, and serves as a great example of the sorts of attacks enabled by speculative execution leaks.

Farewell SETI@Home

March 6, 2020 by 59 Comments

It was about 21 years ago that Berkley started one of the first projects that would allow you to donate idle computing time to scientific research. In particular, your computer could help crunch data from radio telescopes looking for extraterrestrial life. Want to help? You may be too late. The project is going into hibernation while they focus on analyzing data already processed.

According to the home page:

We’re doing this for two reasons:

1) Scientifically, we’re at the point of diminishing returns; basically, we’ve analyzed all the data we need for now.

2) It’s a lot of work for us to manage the distributed processing of data. We need to focus on completing the back-end analysis of the results we already have, and writing this up in a scientific journal paper.

Continue reading “Farewell SETI@Home” →

Using IR LEDs To Hide In Plain Sight

February 28, 2020 by 91 Comments

Getting by without falling under the gaze of surveillance cameras doesn’t seem possible nowadays – from malls to street corners, it’s getting more common for organizations to use surveillance cameras to keep patrons in check. While the freedom of assembly is considered a basic human right in documents such as the US Condition and the Universal Declaration of Human Rights, it is not a right that is respected everywhere in the world. Often times, governments enforcing order will identify individuals using image recognition programs, preventing them from assembling or demonstrating against their government.

Freedom Shield built by engineer [Nick Bild] is an attempt at breaking away from the status quo and giving people a choice on whether they want to be seen or not. The spectrum of radiation visible to humans maxes out around 740nm, allowing the IR waves to remain undetected by normal observers.

The project uses 940nm infrared (IR) LEDs embedded in clothes to overwhelm photo diodes in IR-sensitive cameras used for surveillance. Since the wavelength of the lights are not visible to humans, they don’t obstruct normal behavior, making it an ideal way to hide in plain sight. Of course, using SMD LEDs rather than the larger sizes would also help with making the lights even less visible to the naked eye.

The result doesn’t perfectly obscure your face from cameras, but for a proof-of-concept it’s certainly a example of how to avoid being tracked.

Continue reading “Using IR LEDs To Hide In Plain Sight” →

This Week In Security: Chrome Bugs And Non-bugs, Kr00k, And Letsencrypt

February 28, 2020 by 20 Comments

Google Chrome minted a new release to fix a trio of bugs on Monday, with exploit code already in the wild for one of them. The first two bugs don’t have much information published yet. They are an integer-overflow problem in Unicode internationalization, and a memory access issue in streams. The third issue, type confusion in V8, was also fixed quietly, but a team at Exodus Intel took the time to look at the patches and figure out what the problem was.

The actual vulnerability dives into some exotic Javascript techniques, but to put it simply, it’s possible to change a data-type without V8 noticing. This allows malicious code to write into the header area of the attacked variable. The stack, now corrupted, can be manipulated to the point of arbitrary code execution. The researchers make the point that even with Google’s fast-paced release schedule, a determined attacker could have several days of virtual zero-day exploitation of a bug mined from code changes. Story via The Register.

The Chrome Problem that Wasn’t

A second Chrome story came across my desk this week: Chrome 80 introduces a new feature, ScrollToTextFragment. This useful new feature allows you to embed a string of text in a URL, and when loading that address, Chrome will scroll the page to make that text visible. For certain use cases, this is an invaluable feature. Need to highlight a specific bit of text in a big document online?

The following bookmarklet code by [Paul Kinlan] is the easy way to start using this feature. Paste this code into the URL of a bookmark, put it on the bookmark bar, highlight some text in a webpage, and then run the bookmarklet. It should open a new tab with the new URL, ready to use or send to someone.

javascript:(function()%7Bconst%20selectedText%20%3D%20getSelection().toString()%3Bconst%20newUrl%20%3D%20new%20URL(location)%3BnewUrl.hash%20%3D%20%60%3A~%3Atext%3D%24%7BencodeURIComponent(selectedText)%7D%60%3Bwindow.open(newUrl)%7D)()

Since we’re talking about it in the security column, there must be more to the story. A privacy guru at Brave, [Peter Snyder], raised concerns about privacy implications of the feature. His argument has been repeated and misrepresented in a few places. What argument was he making? Simply put, that it’s not normal user behavior to immediately scroll to an exact position on the page. Because modern web pages and browsers do things like deferred loading of images, it could be possible to infer where in the page the link was pointing. He gives the example of a corporate network where DNS is monitored. This isn’t suggesting that the entire URL is leaked over DNS, but rather that DNS can indicate when individual components of a page are loaded, particularly when they are embedded images from other sites.

While this concern isn’t nonsensical, it seems to me to be a very weak argument that is being over-hyped in the press.

Whatsapp Groups Searchable on Google

It’s not new for search engines to index things that weren’t intended to be public. There is a bit of mystery surrounding how Google finds URLs to index, and StackExchange is full of plenty of examples of webadmins scratching their heads at their non-public folders showing up in a Google search.

That said, a story made the rounds in the last few days, that WhatsApp and Telegram group invites are being indexed by Google. So far, the official word is that all the indexed links must have been shared publicly, and Google simply picked them up from where they were publicly posted.

It appears that WhatsApp has begun marking chat invitation links as “noindex”, which is a polite way to ask search engines to ignore the link.

If it’s shown that links are getting indexed without being posted publicly online, then we have a much bigger story. Otherwise, everything is working as expected.

Letsencrypt Makes Attacks Harder

Letsencrypt has rolled out an invisible change to their validation process that makes a traffic redirection attack much harder. The new feature, Multi-Perspective Validation, means that when you verify your domain ownership, Letsencrypt will test that verification from multiple geographic regions. It might be possible to spoof ownership of a domain through a BGP attack, but that attack would be much harder to pull off against traffic originating from another country, or multiple countries simultaneously. Letsencrypt is currently using different regions of a single cloud, but plans to further diversify and use multiple cloud providers for even stronger validation.

Kr00k

Brought to us by the researchers at Eset, Krook (PDF) is a simple flaw in certain wireless chips. So far, the flaw seems to be limited to WPA2 traffic sent by Broadcom and Cypress chips. They discovered Kr00k while doing some followup research on KRACK.

Let’s talk about WPA2 for a moment. WPA2 has a 4-way handshake process that securely confirms that both parties have the shared key, and then establishes a shared Temporal Key, also known as a session key. This key is private between the two devices that performed the handshake, meaning that other devices on the same wireless network can’t sniff traffic sent by other devices.

When a device disconnects, or disassociates, that session key is reset to all 0s, and no packets should be sent until another handshake is performed. Here’s the bug: The packets already in the output buffer are still sent, but are encrypted with the zeroed key, making them trivially decrypted. As it’s simple to trigger deauthentication events, an attacker can get a sampling of in-the-clear packets. The ubiquity of TLS is a saving grace here, but any unencrypted traffic is vulnerable. Eset informed vendors about the flaw in 2019, and at least some devices have been patched.

Exchange

Microsoft Exchange got a security patch this past Tuesday that addressed a pair of bugs that together resulted in a remote code execution vulnerability. The first bug was an encryption key that is generated on Exchange server installation. That generation seemed to lack a good source of entropy, as apparently every Exchange install uses the the exact same key.

The second half of this bug is a de-serialization problem, where an encrypted payload can contain a command to run. Because the encryption key is known, any user can access the vulnerable endpoint. The process of exploitation is so trivial, be sure to patch your server right away.

TODO: Remove Vulnerabilities

This one is just humorous. An Intel virtualization feature appears to have been pushed into the Linux kernel before it was finished. Know what unfinished code tends to contain? Bugs and vulnerabilities. CVE-2020-2732, in this case. It’s unclear how exactly an exploit would work, but the essence is that a virtual guest is allowed to manipulate system state in unintended ways.