Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
unknown
Nov 16, 2002
Ain't got no stinking title yet!


Say hello to the new linux kernel root vunerability CVE-2016-0728 released today before your vendor can do anything about it.

http://perception-point.io/2016/01/14/analysis-and-exploitation-of-a-linux-kernel-vulnerability-cve-2016-0728/ posted:

Introduction
The Perception Point Research team has identified a 0-day local privilege escalation vulnerability in the Linux kernel. While the vulnerability has existed since 2012, our team discovered the vulnerability only recently, disclosed the details to the Kernel security team, and later developed a proof-of-concept exploit. As of the date of disclosure, this vulnerability has implications for approximately tens of millions of Linux PCs and servers, and 66 percent of all Android devices (phones/tablets). While neither us nor the Kernel security team have observed any exploit targeting this vulnerability in the wild, we recommend that security teams examine potentially affected devices and implement patches as soon as possible.

In this write-up, we’ll discuss the technical details of the vulnerability as well as the techniques used to achieve kernel code execution using the vulnerability. Ultimately, the PoC provided successfully escalates privileges from a local user to root.

The Bug
CVE-2016-0728 is caused by a reference leak in the keyrings facility. Before we dive into the details, let’s cover some background required to understand the bug.

Quoting directly from its manpage, the keyrings facility is primarily a way for drivers to retain or cache security data, authentication keys, encryption keys and other data in the kernel. System call interfaces – keyctl syscall (there are two other syscalls that are used for handling keys: add_key and request_key. keyctl, however, is definitely the most important one for this write-up.) are provided so that userspace programs can manage those objects and use the facility for their own purposes.

Each process can create a keyring for the current session using keyctl(KEYCTL_JOIN_SESSION_KEYRING, name) and can choose to either assign a name to the keyring or not by passing NULL. The keyring object can be shared between processes by referencing the same keyring name. If a process already has a session keyring, this same system call will replace its keyring with a new one. If an object is shared between processes, the object’s internal refcount, stored in a field called usage, is incremented. The leak occurs when a process tries to replace its current session keyring with the very same one. As we see in the next code snippet, taken from kernel version 3.18, the execution jumps to error2 label which skips the call to key_put and leaks the reference that was increased by find_keyring_by_name.

...full code and more at the link...

Adbot
ADBOT LOVES YOU

unknown
Nov 16, 2002
Ain't got no stinking title yet!


I'm not saying they didn't disclose, but just gave a very small embargo window to one vendor (https://bugzilla.redhat.com/show_bug.cgi?id=1297475 / https://bugzilla.novell.com/show_bug.cgi?id=CVE-2016-0728) to fix across multiple vendors before doing a very public disclosure with working exploits - all before anyone could really get a tested patch in place/released.

Semi responsible security research info release, good for maximum media attention basically. :shrug: Won't be the first, won't be the last.

unknown
Nov 16, 2002
Ain't got no stinking title yet!


Back to infosec...

Literally :10bux: gets you a usb U2F/Fido security key from amazon. (https://www.hypersecu.com/products/hyperfido) Half the price of Yubico..

No reason to not do it any more.

unknown
Nov 16, 2002
Ain't got no stinking title yet!


Well, if you're in Canada, it's $9.99cdn with free 2day/prime shipping. That's what, like $7.50 usd?

https://www.amazon.ca/HyperFIDO-Mini-U2F-Security-Key/dp/B01LZO0WE9

I'm not sure if it's possible to get cheaper.

Makes me wonder if something is wrong with these tokens. :ohdear:

unknown
Nov 16, 2002
Ain't got no stinking title yet!


Anyone got recommendations/horror stories on cloud SSO providers? (eg: onelogin, bitium, etc)

Was just asked about it from someone that's running Gsuite and wants to do some auth integration against it, but gear doesn't directly support it (this is to do 802.1x auth - they've seen the light about wifi).

unknown
Nov 16, 2002
Ain't got no stinking title yet!


2fa sms is never going away because it allows them to link your account to a cell phone number which then make your data easier to link to external databases.

unknown
Nov 16, 2002
Ain't got no stinking title yet!


So IBM is now taking on Google on their home turf by literally "1 up"ping them.

https://quad9.net

quote:

How Quad9 works

Quad9 routes your DNS queries through a secure network of servers around the globe. The system uses threat intelligence from more than a dozen of the industry's leading cyber security companies to give a real-time perspective on what websites are safe and what sites are known to include malware or other threats. If the system detects that the site you want to reach is known to be infected, you'll automatically be blocked from entry - keeping your data and computer safe.

That's right. IBM is now running a public anycast DNS service at 9.9.9.9 with the idea that all queries run through their advanced security screening system to block bad hostnames.

IBM being IBM also registered quad9.com and forgot that their *.quad9.net ssl certificate doesn't cover it. :eng99:

unknown
Nov 16, 2002
Ain't got no stinking title yet!


They (Quad9) claim 9.9.9.10 is the same infrastructure, just without any filtering.

unknown
Nov 16, 2002
Ain't got no stinking title yet!


https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

quote:

... (much clipped) ...

Impact

It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the contents of protected kernel memory.

The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.

Whenever a running program needs to do anything useful – such as write to a file or open a network connection – it has to temporarily hand control of the processor to the kernel to carry out the job. To make the transition from user mode to kernel mode and back to user mode as fast and efficient as possible, the kernel is present in all processes' virtual memory address spaces, although it is invisible to these programs. When the kernel is needed, the program makes a system call, the processor switches to kernel mode and enters the kernel. When it is done, the CPU is told to switch back to user mode, and reenter the process. While in user mode, the kernel's code and data remains out of sight but present in the process's page tables.

Think of the kernel as God sitting on a cloud, looking down on Earth. It's there, and no normal being can see it, yet they can pray to it.

These KPTI patches move the kernel into a completely separate address space, so it's not just invisible to a running process, it's not even there at all. Really, this shouldn't be needed, but clearly there is a flaw in Intel's silicon that allows kernel access protections to be bypassed in some way.

The downside to this separation is that it is relatively expensive, time wise, to keep switching between two separate address spaces for every system call and for every interrupt from the hardware. These context switches do not happen instantly, and they force the processor to dump cached data and reload information from memory. This increases the kernel's overhead, and slows down the computer.

Your Intel-powered machine will run slower as a result.

... (more clipped) ...

However, it may be that the vulnerability in Intel's chips is worse than the above mitigation bypass. In an email to the Linux kernel mailing list over Christmas, AMD said it is not affected. The wording of that message, though, rather gives the game away as to what the underlying cockup is:

"AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."

A key word here is "speculative." Modern processors, like Intel's, perform speculative execution. In order to keep their internal pipelines primed with instructions to perform, the CPU cores try their best to guess what code is going to be run next, fetch it, and execute it.

It appears, from what AMD software engineer Tom Lendacky was suggesting above, that Intel's CPUs speculatively execute code potentially without performing security checks. It seems it may be possible to craft software in such a way that the processor starts executing an instruction that would normally be blocked – such as reading kernel memory from user mode – and completes that instruction before the privilege level check occurs.

... (more clipped) ...

unknown fucked around with this message at 02:31 on Jan 3, 2018

unknown
Nov 16, 2002
Ain't got no stinking title yet!


Google's posting on it (lots of technical details):

https://googleprojectzero.blogspot.ca/2018/01/reading-privileged-memory-with-side.html?m=1

quote:

...(clipped)...
So far, there are three known variants of the issue:

Variant 1: bounds check bypass (CVE-2017-5753)
Variant 2: branch target injection (CVE-2017-5715)
Variant 3: rogue data cache load (CVE-2017-5754)

Before the issues described here were publicly disclosed, Daniel Gruss, Moritz Lipp, Yuval Yarom, Paul Kocher, Daniel Genkin, Michael Schwarz, Mike Hamburg, Stefan Mangard, Thomas Prescher and Werner Haas also reported them; their [writeups/blogposts/paper drafts] are at:

Spectre (variants 1 and 2)
Meltdown (variant 3)

During the course of our research, we developed the following proofs of concept (PoCs):

- A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries.

- A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4]

- A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn't been tested.)

- A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache.

...(much clipped)...

unknown
Nov 16, 2002
Ain't got no stinking title yet!


If you're comfortable with doing things yourself, voip.ms is actually fairly decent and cheap for putting a number on as they charge by usage (1c/min, plus like $1/mo for a number) generally with pops throughout North America. Any sip client works, and they've got a no-frills sms app too.

unknown
Nov 16, 2002
Ain't got no stinking title yet!


CarForumPoster posted:

TY. I ended up saying gently caress it just try the VPN and that worked. Going to just run all my scrapers through ExpressVPN. Small slowdown but not a big deal in the scheme of things.

Its a temp fix as we plan to migrate these scrapers to AWS lambda functions and at that point I'll have to figure out the proxy situation.

Use a tiny ssh server somewhere and use ssh's built in socks proxy capability? (-D option)

unknown
Nov 16, 2002
Ain't got no stinking title yet!


Thanks Ants posted:

CSP lets resellers make margin, so instead of paying Microsoft $x per month for your licensing, you can pay the same amount to a reseller but they will help you out when you need assistance because they're now making money off the deal. CSP licenses are also all pro-rated to the day, so there's no annual commitment to get the advertised pricing which actually makes it quite a lot cheaper if you need the flexibility of changing licence counts down as well as up more than once a year.

That plus the number of companies that just have issues dealing with purchasing on credit cards is astounding because they have no other way of keeping control of their spending. (ie: accounting departments get to audit invoices before paying them)

unknown
Nov 16, 2002
Ain't got no stinking title yet!


Zorak of Michigan posted:

I have a vanity domain hosted at fastmail.com for my personal email, and when I have to register for a site that I'd rather didn't have my real email, I just register a new alias with the name of the site @ my vanity domain. IIRC unlimited aliases are included in the basic plan, and I suspect that's common since it's not like they take up a lot of compute cycles.

I have similar one at pobox (now fastmail), and just before they sold they told me that my account was one of the top email spam destinations and wanting to cancel my account - receiving like 200k emails a month because of the anything@domain alias.

After a bit of back and forth turns out they were saving all the emails in the spam system that failed spamhaus rbl lookups.

unknown
Nov 16, 2002
Ain't got no stinking title yet!


I'm sure cisco execs in charge of licensing jizzed everyday when they discovered Meraki and how it effectively bricks the device when the license expires.

unknown
Nov 16, 2002
Ain't got no stinking title yet!


https://twitter.com/p_malynin/status/1469866520939429889

unknown
Nov 16, 2002
Ain't got no stinking title yet!


BrianBoitano posted:

Yeah that's part of my variety of reasons - comparing with Paprika because I hate to admit there's only one good app out there :negative:

IIRC, it (Paprika) is a goon owned project too.

unknown fucked around with this message at 18:21 on May 12, 2022

unknown
Nov 16, 2002
Ain't got no stinking title yet!


Lots of hardware is like that - generally a brilliant person/team comes up with the initial concept, but when the secondary crew (not-so brilliant) comes afterwards, they're tasked with just "get (new) function working" and the product slowly falls apart.

unknown
Nov 16, 2002
Ain't got no stinking title yet!


My dealings with a couple heavily regulated/paranoid companies basically they wouldn't allow any video/chat app except for the ones they approved and controlled/locked down.

As you can guess it was a poo poo show for that company employees. "nooo, let me run the meeting, it's just easier.."

They also bought for the major vendors so that if you did use their non-regular (teams) system - basically they were locked out. :homebrew:

unknown
Nov 16, 2002
Ain't got no stinking title yet!


Too often it's a case of a red team being brought in to bust the network and the network/blue team already know it can be done but there was never buy in by management to finance fixing the holes in the first place.

So it immediately becomes an adversarial relationship from the beginning and its just downhill from there.

unknown
Nov 16, 2002
Ain't got no stinking title yet!


BonHair posted:

I think this is hitting the nail on the head.

If possible, blue team should have documented the issue and sent it and the solution up the chain through all the right channels, so they can just point to it and shrug if anyone gives them poo poo.

You're making the assumption that the blue team even exists and isn't just another title for some admin who's constantly being pulled into other work of greater emergency so never gets a chance to even document an issue in the first place.

Generally that's how it goes in most companies I see.

unknown
Nov 16, 2002
Ain't got no stinking title yet!


FungiCap posted:

Sysadmins/Blue team not being overly defensive when given results from a pen test.

Managers understanding that it's not a dress down of their employees or their capabilities.

Red teamers not being arrogant assholes and being part of the solution.

Pick 2 scenario?

More circular in my opinion:

10) Budget reduction/freeze over time

20) External red team test to see how well the company does [ie: mgmt trying to prove old budget wasn't necessary]

30) Budget increase to fix problems since they didn't "pass"

40) goto 10

This provides lots of political opportunities for boardroom fights and poo poo. A good CEO can stop the cycle, but most aren't that good.

unknown
Nov 16, 2002
Ain't got no stinking title yet!


Biggest issue with small subnets is that most origins don't know how to put the ranges in popular routing registries so they'll get filtered out at various key points (IXs/large providers).

unknown
Nov 16, 2002
Ain't got no stinking title yet!


rear end in the middle?

unknown
Nov 16, 2002
Ain't got no stinking title yet!


Whoever is in the middle is still an rear end for making us drink more.

Adbot
ADBOT LOVES YOU

unknown
Nov 16, 2002
Ain't got no stinking title yet!


Serious Hardware/Software Crap › The Infosec Thread: Yes, time to move off Entrust

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply