Anyone have ideas how to detect passwords in logs?
Logs in High Sierra Show Plaintext Password for APFS Encrypted External Volumes
51–60 of 123 posts
Re: Logs in High Sierra Show Plaintext Password for APFS Encrypted External Volumes
#52Windows users have long waited a year to install new versions. If Mac users did the same they would have fewer such problems.
Lots of Mac users wait before they upgrade. (Myself included)
I recently looked at stats for my app, and only around 60% of my users are on 10.13, 30% on 10.12, and 10% on older versions.
If you use your Mac professionally, there‘s no point in updating every year — it‘s always a hassle and a few weeks of upgrading 3rd party software and fixing random things that don‘t work any more.
Re: Logs in High Sierra Show Plaintext Password for APFS Encrypted External Volumes
#53Earlier quoted context omitted.
Yeah, they just deployed a whole new FS to 100s of millions of users, in record time, with almost zero incidents. Hardly any new features...
> new FS [...] in record time That's an odd brag. I might be from a bygone era but it used to be the case that filesystems were particularly conservative and rollouts equally so. Getting one deployed in "record time" is hardly difficult because everyone else is so conservative it can take tens of years in some cases. Look at Microsoft's ReFS, available in Server 2012, 2012 R2, Windows 8.1, Server 2016 and Windows 10…
>That's an odd brag. I might be from a bygone era but it used to be the case that filesystems were particularly conservative and rollouts equally so. Getting one deployed in "record time" is hardly difficult because everyone else is so conservative it can take tens of years in some cases.
Point missed entirely.
The "hard part" they've managed is getting it right (with few/no incidents) in record time, not just getting it out on record time.
Re: Logs in High Sierra Show Plaintext Password for APFS Encrypted External Volumes
#54Earlier quoted context omitted.
Yeah, they just deployed a whole new FS to 100s of millions of users, in record time, with almost zero incidents. Hardly any new features...
What new features do users gain from the new file system?
Optimized for SSDs, 64-bit inodes, faster timestamping (modification times etc), faster size calculations, faster cloning, safer copies, per-disk and file encryption, space saving sparse files, and more.
Re: Logs in High Sierra Show Plaintext Password for APFS Encrypted External Volumes
#55That's pretty bad. It's been known for decades on other Unix systems that you shouldn't pass passwords by command line parameter, or even support doing so. I guess no-one told Apple.
Not to disagree, but could you provide some references to the statement?
Re: Logs in High Sierra Show Plaintext Password for APFS Encrypted External Volumes
#56Windows users have long waited a year to install new versions. If Mac users did the same they would have fewer such problems.
Windows 10, of course, gives you no choice but to install new versions immediately (besides enterprise deployments, of course). Apple's updates are getting sloppy, but at least they're optional.
Not if you paid for it (Pro version). I never install the latest Windows 10 right away.
Re: Logs in High Sierra Show Plaintext Password for APFS Encrypted External Volumes
#57Earlier quoted context omitted.
Don't recall right now for sure, but doesn't ps have an option to display the processes environment? I've done it by accident a few times and it does not take root.
It has an option (e) to attempt to display environment variables, but ps is just a program that reads from /proc, and the kernel enforces isolation of environment variables by breaking reads to /proc/pid/environ for processes you don't own (or more precisely, can't ptrace), so `ps e` can't show anything for those processes. λ whoami cjb λ cat /proc/1/cmdline /sbin/init% λ cat /proc/1/environ cat: /proc/1/environ: Per…
And if you can see /proc/*/environ, you can probably attach to the process via gdb and read the secret from the process memory. At that point, it's not relevant how the secret was passed to the process.
Unless the secret is some kind of one-time token, or time based token, but then it's also not relevant how the secret was passed to the process. It's invalidated soon.
Re: Logs in High Sierra Show Plaintext Password for APFS Encrypted External Volumes
#58What exactly happened to macOS development at Apple? There's always bad luck but Apple has had multiple very visible and very serious vulnerabilities over the last few quarters. They've made multiple grave errors with encrypted volumes. I don't think Microsoft with Bitlocker or Linux with dm-crypt has ever made mistakes as bad as Apple has made here and multiple other times.
Forget the stability issues, a lot of the vulnerabilities are very alarming. I'm by no means a cryptographer, I should not be allowed anywhere near any security sensitive code and yet of course I know that command line options are accessible by all. All it takes is a glance at ps to realize that this exposes the password so how exactly was this functionality added to both the UI and CLI without anyone realizing what a blunder this was? This reminds me of the bug where the System Preferences app would perform privileged operations by basically calling an undocumented API that would create an arbitrary file with arbitrary data and arbitrary permissions (including SUID) as root. What's worse is that Apple already "fixed" a vulnerability in that API when in reality all they did was modify the API client to not run if the user wasn't root.
Why does it seem like there's no real oversight on macOS development anymore? An implementation bug or a complex design that leads to a vulnerability is one thing but so many of these vulnerabilities should have stuck out as a terrible design from the start.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1775
Re: Logs in High Sierra Show Plaintext Password for APFS Encrypted External Volumes
#59Earlier quoted context omitted.
> new FS [...] in record time That's an odd brag. I might be from a bygone era but it used to be the case that filesystems were particularly conservative and rollouts equally so. Getting one deployed in "record time" is hardly difficult because everyone else is so conservative it can take tens of years in some cases. Look at Microsoft's ReFS, available in Server 2012, 2012 R2, Windows 8.1, Server 2016 and Windows 10…
How’s that Takata airbag treating you? Hope it’s as reliable as the acceleration is “unintended”… http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUB...
"Takata airbag"
That is an interesting recall. I was thinking about it today as my girlfriend is getting one replaced on her car right now. She commented on the incompetence of repair people these days and how they didn't even know if the repair was going to take one day or a week.
With the death toll from the airbags at only 22 globally so far [1] and maybe a few hundred injuries [2] and a total number of recall repairs at 65-70 million [3], you can bet the number bad repairs are going to cause more deaths than if they had not done the recall. Plus the cost of the recall in the billions of dollars that could have done a lot more good. I guess the lawyers are coming out alright though.
[1]http://www.thedrive.com/sheetmetal/18154/death-toll-continue...
[2]https://consumerist.com/2015/04/27/takata-airbag-defect-now-...