Yesterday, infosec research firm SentinelLabs revealed twelve year old flaws in Dell’s firmware updater, DBUtil 2.3. The vulnerable firmware updater has been installed by default on hundreds of millions of Dell systems since 2009.
The five high severity flaws SentinelLabs discovered and reported to Dell lurk in the dbutil_2_3.sys module, and have been rounded up under a single CVE tracking number, CVE-2021-21551. There are two memory corruption issues and two lack of input validation issues, all of which can lead to local privilege escalation, and a code logic issue which could lead to a denial of service.
A hypothetical attacker abusing these vulnerabilities can escalate the privileges of another process, or bypass security controls to write directly to system storage. This offers multiple routes to the ultimate goal of local kernel-level access—a step even higher than Administrator or “root” access—to the entire system.
This is not a remote code execution vulnerability—an attacker sitting across the world, or even across the coffee shop, cannot use it directly to compromise your system. The major risk is that an attacker who gets an unprivileged shell via some other vulnerability can use a local privilege escalation exploit like this one to bypass security controls.
Since SentinelLabs notified Dell in December 2020, the company has provided documentation of the flaws, and mitigation instructions which for now boil down to “remove the utility.” A replacement driver is also available, and should be automatically installed at the next firmware update check on affected Dell systems.
SentinelLabs’ Kasif Dekel was at least the fourth researcher to discover and report this issue, following CrowdStrike’s Satoshi Tanda and Yarden Shafir, and IOActive’s Enrique Nissim. It’s not clear why it took Dell two years and three separate infosec companies’ reports to patch the issue—but to paraphrase CrowdStrike’s Alex Ionescu above, what matters most is that Dell’s users will finally be protected.
After years of flirting with the idea of opening a physical store, Google announced its first-ever permanent retail location last month. Today, June 17, is the official grand opening, and Google celebrated with a blog post detailing what the store is like.
Officially, this is “The Google Store Chelsea,” and it lives in New York City on 15th and 9th, aka the Chelsea Market building, aka the headquarters of Google’s New York City campus. Unlike the stark white Apple Stores that Google is chasing after, the Google Store has a natural look, with warm wood walls and furniture. Whimsical bendy rods shoot out of the floor and decorate the store, looking like a giant version of a bead maze from a pediatrician’s office. The store was designed by Ivy Ross, Google’s VP of hardware design.
What can you buy in a Google Store? It’s essentially an offline version of store.google.com. That means it will sell Pixel phones, earbuds, Pixelbook laptops, Chromecasts, Google TVs, Stadia controllers, and Nest-branded speakers, smart displays, thermostats, smoke detectors, cameras, Wi-Fi routers, and doorbells. Google also notes that it will “have experts on hand to help visitors get the most out of their device, such as troubleshooting an issue, fixing a cracked Pixel screen, or helping with installations.”
“Sandbox” areas for Pixel, Stadia, and Nest will pitch customers on the benefits of each product line. The Pixel area shows off the phone’s camera technology with various lighting effects; the Stadia area is one of the only places the public can actually try the game streaming service; and the Nest section is a big living room full of smart home devices. A “workshop” space will host regular events and lessons. There’s also a rotating exhibit called the “Google Imagination Space,” a “17-foot-tall circular glass structure” that surrounds a visitor with several vertical screens. Right now, it’s pitching Google Translate, and visitors can “experience real-time translation of your speech into 24 languages simultaneously and then learn how this all happens on the back end using several Google technologies.”
A one-off store or the start of a Googley retail empire?
It’s hard to say if this is a one-off vanity store for Google’s NYC HQ or if Google is getting serious about retail. One of the co-authors of the blog post is “Nathan Allen, Head of Store Design & Special Projects,” which is a very interesting title for someone at a company with a single retail store. According to Allen’s LinkedIn, he held the title of “Head of Design for Experiential & Special Projects” until two months ago, but “Head of Store Design” apparently provides enough work to be his full-time job now. The blog post also notes that during the development of the store, Google “built a full-scale mockup of the space at our retail hangar in Mountain View.” Again, having a “retail hangar” to experiment with sounds like part of a process rather than a one-off thing.
Apple has over 500 physical Apple Stores, but the company is also a hardware juggernaut. It’s not clear if Google’s limited and inconsistent hardware selection can support a retail store. Microsoft is in a similar boat as Google, shipping low-volume, aspirational hardware in an ecosystem flooded with compromised partner devices. Microsoft started its retail store idea in 2009 and ended up getting out of the space in 2020.
Regardless of Google’s future retail plans, this Google Store is going to be a special case. Google owns this entire building, so it’s not risking much as a retail venture since the property costs are accruing anyway. Google is turning 5,000 square feet of the ground floor from what could be office space into a public retail store. If the idea works out, maybe the company will build more stores. If not, the store can either stick around as a vanity project or can go back to being office space.
I wonder what happens if you walk into the store and shout, “Hey, Google.”
Apple has been under a mountain of scrutiny lately from legislators, developers, judges, and users. Amidst all that, CEO Tim Cook sat with publication Brut. to discuss Apple’s strategy and policies. The short but wide-ranging interview offered some insight into where Apple plans to go in the future.
As is so common when Tim Cook speaks publicly, privacy was a major focus. His response to a question about its importance was the same one we’ve heard from him many times: “we see it as a basic human right, a fundamental human right.” Noting Apple has been focused on privacy for a long time.
You can think of a world where privacy is not important, and the surveillance economy takes over and it becomes a world where everyone is worried that somebody else is watching them, and so they begin to do less, they begin to think less, and nobody wants to live in a world where that freedom of expression narrows.
And when asked about regulatory scrutiny, he pointed to the GDPR as an example of regulation Apple supports and also said Apple would support further expanding privacy-related regulations.
But beyond regulations strictly centered on privacy, he wasn’t as effusive. “As I look at the tech regulations that’s being discussed, I think there are good parts of it and then I think there are parts of it that are not in the best interests of the user,” he said.
As an example of the latter, he said “the current DMA language that is being discussed would force sideloading on the iPhone.” He added:
That would destroy the security of the iPhone and a lot of the privacy initiatives that we’ve built into the App Store, where we have privacy nutrition labels and App Tracking Transparency… these things would not exist anymore.
Privacy watchdogs have praised Apple’s App Tracking Transparency move even as advertisers have lambasted it, but the nutrition labels have been less of a hit. Many observers have pointed out that the labels are often inaccurate or incomplete.
“Android has 47 times more malware than iOS does,” Cook claimed. “It’s because we’ve designed iOS in such a way that there’s one app store and all of the apps are reviewed prior to going on the store. And so that keeps a lot of this malware stuff out of our ecosystem, and customers have told us very continuously how much they value that, and so we’re going to be standing up for the user in the discussions.”
The interview wasn’t all about regulation and privacy, though; Cook also responded to open-ended questions about Apple’s future product strategy. When asked what he believes Apple’s products will look like many years from now, he carefully offered the caveat that no one can really predict where things are headed:
We approach the future with great humility because we know we can’t predict it. I’m not one of those people that is going to say I can see 20 years out, and 30 years out, and tell you what is going to happen. I can’t. I really don’t believe anyone can.
To back that point, he talked about Apple’s path towards putting its own silicon in Macs:
We didn’t know when we were working on the chip for the iPhone that it would become the heart of the iPad, and we didn’t know that it would eventually become the heart of the Mac as it just did in this past year. We didn’t know that, but we kept discovering, and we kept pulling the string, and we kept our minds open about where that journey would take us, and it’s taken us somewhere that’s incredible and that has a great future ahead of it.
That said, Cook named augmented reality (AR) and the intersection of health and tech as areas where he sees future potential. He said he sees AR “as a technology that can enhance life in a broad way.” And once again hinting at ambitions plans for future AR hardware, he said: “We’ve been working on AR first with our phones and iPads, and later we’ll see where that goes in terms of products.”
On the health side, Cook said he is “exceedingly optimistic” about the intersection of health and technology:
You know, when we started shipping the Watch, we did so thinking about it from a wellness point of view, but we put a heart rate sensor on it, and I was getting tons of emails about people that found out they had heart problems that they didn’t know about it. And so we started adding more function to the Watch… and I begin to get even more notes from people that found that they’d had a problem because of this ability to continually monitor themselves. I think the idea of continually monitoring the body, much like happens in your car with warning lights and so forth, I think this is a big idea that has a long road path ahead of it. All of those things make me incredibly optimistic.
The mention of a car as inspiration drew a smirk from Brut.’s interviewer, who shortly afterwards asked if Apple plans to design and begin selling a car. “In terms of a car,” Cook answered, “I’ve gotta keep secrets, and there always has to be something up our sleeve.”
The European Union’s General Data Protection Regulation (GDPR), passed in 2018, requires websites to ask visitors for consent prior to placing cookies. As any Internet user is now aware, this means an extra step required when visiting nearly any website for the first time—or potentially every time, if you choose not to accept cookies. A new proposed HTTP standard from None of Your Business and the Sustainable Computing Lab would allow the user to set their privacy preferences once, inside the browser itself, and have the browser communicate those preferences invisibly with any website the user visits.
Advanced Data Protection Control
The proposed standard enables two methods of automated preference delivery—one which communicates directly with the web server hosting a site being visited, and another which communicates with the website itself.
Consent requests resource
"cookies": "Store and/or access cookies on your device.",
"ads_profiling": "Create a personalised ads profile."
In HTTP-based ADPC, the webserver links to the consent file directly in its response to an HTTP GET:
HTTP/1.1 200 OK
Link: </consent-request-resource.json>; rel="consent-requests"
When the web browser detects this link, it can either respond with previously user-configured settings or request an answer from the user via a pop-up dialog (most likely, one spawned from the browser’s lock button). Once the user has set their preferences accordingly, the browser includes an ADPC header on future HTTP GET requests:
GET /page.htm HTTP/1.1
ADPC: withdraw=*, consent=cookies
In the above example, we see a configuration similar to what one might see on a network firewall: a default DENY in the form of withdraw=*, overridden by a specific acceptance of cookies. So for our website which wanted both to set cookies and create an advertising profile, the cookie request is granted (allowing storage of, e.g., user authentication and personal settings), but advertising profile is denied.
Another benefit of the ADPC scheme is that the user is interacting with their own browser, with consistent UI regardless of website. Another benefit is that it’s possible for the user to set persistent preferences for a site without needing to allow cookies—something which isn’t possible for a website which must ask for consent via a banner embedded in the webpage itself.
Finally, cookie banners may frequently not be displayed at all—in our testing, popular ad-blocking plugins blocked the display of many cookie banners, including but not limited to The Guardian’s. Such blocking can be due to collateral damage caused by overly aggressive block rules or deliberate attempts to minimize “click fatigue.” In either case, they prevent the user from directly expressing consent or refusal to privacy-related issues.
Request, not command
It’s important to realize that ADPC is not a mechanism for enforcing a user’s privacy profile—it’s simply a normalized way of requesting it in compliance with the European Union’s GDPR and similar privacy laws elsewhere.
Nothing technically prevents a hypothetical ADPC-compliant website from requesting permission to create an advertising profile for a user, being denied, and then creating that profile anyway. But legitimate sites can request consent in a more machine-readable, consistent, and less user-fatiguing way.
ADPC does still assist users in dealing with shady sites that ignore their users’ preferences—in the event of a GDPR or other lawsuit, users’ preferences are more likely to be logged and readable from their own systems. If a user refuses to accept any cookies via a cookie banner, their expressed preference cannot be saved and logged—but ADPC preferences will be.
Even if a user interacting with a cookie banner accepts cookies (but disables ad profiling), that cookie is much more likely to be mistakenly “cleaned” by the user themselves. That “cleaning” could be in the quest to maintain privacy or even fix problems with frequently visited websites. Since ADPC preferences are only good for that one thing—expressing or refusing consent on privacy issues—there is much less reason for them to be destroyed.