Make-me-admin holes found in Windows, Linux kernel Move over, PrintNightmare. Microsoft has another privilege-escalation hole in Windows that can be potentially exploited by rogue users and malware to gain admin-level powers. Meanwhile, a make-me-root hole was found in recent Linux kernels. Recent builds of Windows 10, and the preview of Windows 11, have a misconfigured …
It's just bad English created by marketurds* to sound clever.
"Leverage" is a noun being used as a verb for no reason.
You've actually got the answer in your own post: "leverage" -> simply "use". (I know I've twisted your context.)
Yeah, languages evolve, but for the love of Jeebus!
* The irony is not lost on us, right? lol
"'Leverage' is a noun being used as a verb for no reason."
Both dictionary.com and Merriam-Webster list it as a verb. The language has already evolved, too late to complain. The second M-W verb example seems particularly relevant:
"Definition of leverage, transitive verb 2 : to use for gain : exploit"
Do you moaners also have a problem with the word 'exploit' in computer security? :)
"I exploited the vulnerability in the system" -> Implies gaining access to the system
"I used the vulnerability in the system" -> For what? To help write an exploit for a bug bounty program?
"I leveraged the password hash" -> Implies to crack the password
"I used the password hash" -> For what? To check the user's submitted password was correct?
Of course these are sentence fragments (the original in a bullet-point). A full sentence should specify the goal being leveraged toward and then the implication is less helpful but here it seems to me to do the job of narrowing down the type of usage very well.
It's never too late to complain.
It's never too late to call out bullshit management speak. Leverage is used when you want to say "used" but want to sound clever.
I'm quite happy to carry on complaining about that bollocks indefinitely.
I already said I accept language continuously evolves.
However I'll question your sources:
1. Merriam-Webster Dictionary. Take America's most trusted dictionary
2. Dictionary.com (which I also use), but where's its provenance?
Due to the separation of British and American English, I'm happy for our Left Pondian friends to develop their own dialect. Don't expect me to accept it in British English though*.
As far as I know, "exploit" has for a long time been both noun and verb, so I don't see your point there.
"I leveraged the password hash" -> Implies to crack the password
If "leveraged" was replaced with "exploited" no inference would be required. Sounds like someone's using a euphemism to try to hide nefarious activities!
"I used the password hash" -> For what? To check the user's submitted password was correct?
Well, that^ is what it's for!
* Yeah, I know "leverage" is a verb in British dictionaries too - a crying shame I tells ya!
I've no problem with leverage being a verb in the British dictionaries.
Oxford dictionaries define it as:
verb
1.
use borrowed capital for (an investment), expecting the profits made to be greater than the interest payable.
"without clear legal title to their assets, they own property that cannot be leveraged as collateral for loans"
2.
use (something) to maximum advantage.
"the organization needs to leverage its key resources"
Using leverage as a verb in terms of finance is fine.
The second definition is management speak but even still doesn't really work with the original sentence:
"I [used] the password hash [to maximum advantage]"
Note the OED is a descriptive dictionary, which seeks to document the language as it is used. Since the use of "leverage" as a verb is widespread, you'd expect to see it in the OED and other descriptive dictionaries.
While I'm a staunch descriptivist myself (because prescriptivism has no foundation), I have no problem sneering at usage I find unpalatable, including the use of "leverage" as a verb. Style is subjective, but that's no reason not to criticize it.
Good grief. It's a CERT Coordination Center document, from a database funded by the US Federal government, and authored by a man who appears to have been born, educated, and worked his entire life in America and you expect them to use British English definitions of words? That ship sailed many centuries ago.
"As far as I know, 'exploit' has for a long time been both noun and verb"
A long time yes, but before that it was only a noun and presumably there were fuddy-duddies up in arms about it changing. Yet it did and our language is the more nuanced for it. Using one yourself while baulking at someone else's use of the other seems to make you a hypocrite, doesn't it? Both can be replaced with 'use' with only minor(*1) loss of meaning(*2).
(*1) small
(*2) intention
It's because of the EU and its Free Movement Of Vowels requirement. Britain got swamped by all these East European vowels willing to work in words for little more than the price of some extra ink or pixels. And there's a real humanitarian cost, too: you go over to Eastern Europe nowadays and all their cities and whatnot are left with names like Brno and Zczsczt.
The situation is expected to sort itself out after a while though, now that the Brits have finally achieved Brxt.
@9Rune5: Plausible, and I congratulate you on trying to put apositive spin on this, but to a native English speaker the verb "leverage" is just so awful that the it just implies that the speaker is a fucking twat who should be throttled with their own intestines.
Doubtless there are similar constructions in your own mother tongue that provoke similar revulsion.
Mmm. Of course "surface" as an intransitive verb has been well-established for at least decades – consider "the submarine surfaced" or the Boomtown Rats' album The Fine Art of Surfacing, for example.
And as a transitive verb it's been used for a long time as a term of art in construction, e.g. "we resurfaced the exterior with stucco". There it doesn't irritate me, perhaps due to familiarity, though its context as well-established jargon helps.
But yes, the growing popularity of the transitive verb in other contexts such as user interfaces – "the drop control surfaces additional controls for advanced features" – is abominable and should be met with disdain. This usage seems to be a condensation of "brings to the surface", which is already a circumlocution for "reveals" and other more-concise diction. It's false elevation (ooh, "surface", how sophisticated!), a particularly annoying form of anti-pragmatics.
The writer either has a meaning and cannot express it, or he inadvertently says something else, or he is almost indifferent as to whether his words mean anything or not. This mixture of vagueness and sheer incompetence is the most marked characteristic of modern English prose, and especially of any kind of political writing. As soon as certain topics are raised, the concrete melts into the abstract and no one seems able to think of turns of speech that are not hackneyed: prose consists less and less of words chosen for the sake of their meaning, and more and more of phrases tacked together like the sections of a prefabricated hen-house. I list below, with notes and examples, various of the tricks by means of which the work of prose-construction is habitually dodged.
From George Orwells's essay on English Language:-
"Use account password hashes" would have triggered people saying you can't use hashes, that's the point of hashing them.
"Exploit password hashes" would have triggered people saying that in ICT you exploit vulnerabilities.
"Leverage password hashes" triggers people who don't like language developing and changing. When writing reports for old-fashioned managers or grant applications that might be read by comma pedants, that might be best avoided.
Among readers of a technical news site, however, triggering the third group may be the best option and the most fun.
For me the particular idiocy of verbing "leverage" has always been the fact that it was nouned from an existing word, "lever" — a word that's already both a noun and a verb — plus a suffix. I like language developing and changing, but I don't like redundancy or inefficiency. It's doubleplusungood.
To rail against the very existence of the word "leverage" is to regret a coinage that's at least 297 years old, maybe more, and so well-established that it was used in a figurative sense by Gladstone writing about Homer in 1858.
What's more, your premise that we already had "lever" and there was no need to add to it misses the change in meaning and the difference in usage. "Leverage" is no more the same as "lever" than "coinage" or "usage" are the same as their roots.
systemd what could possibly go wrong with this ubiquitous and IMHO anti-ideological monolith?
At the very least please can Linus and friends just say that PID 1 is ours. Mess it up and you panic the system so only grown ups should be allowed to play here.
If you need the process termination notifications the the orphan catcher gets, come talk to us, we'll give you an API, but just leave PID 1 to those who act responsibly.
I've never had to make so many side searches as I did to be able to understand this article.
Silver ticket ? Ok, now I know what that is.
VSS ? Should be called VSC. It's disabled on my machine.
Mimikatz ? Never heard of it. Thankfully, its home page is quite simple to understand.
I think I've already hit my quota of learning for the day, and it's not even beer o'clock.
"C:\The Linux vulnerability involves creating a very long path name.\ That's Very Long(tm) since the length needs to overflow a 32-bit integer.\ It reminds me that (once upon a time) there were limits on the permissible lengths of filenames and although those limits were set much longer than any reasonable human being would ever be bothered to type, they meant that all sorts of software could use a fixed size buffer and not worry about million-character path lengths.\ Sadly, the pursists insisted that there was simply no reason to limit pathnames and so all software must pass torture tests in this area.\ Back in the day, even UNIX systems had a limit (around 4096 characters, I believe, at least on some systems) but gradually the purists have ground everyone else down. Even MS have belatedly gone down this path.\ But really, just *what* is the fucking point of this post being a valid filename? (There, just to trigger another set of purists, I've included wild-card characters in a filename.)\
Actually, if I'm going to be *really* anal I should include a paragraph break, in the form of newline characters, but I'm getting a bit off topic. The real point is that although *you*, dear end-user, cannot see any reason to impose a size limit on names, comment fields or whatever, *implementors* have to go several extra miles to actually support this, especially in a performant manner, and one of the costs is bugs like this.\
Really obscure feature that no-one actually uses but which causes security holes. Sigh..."
Windows supports file paths up to 32,767 characters. You just have to use the "\\?\" prefix or on some Windows versions enable the feature for 'normal' paths.
Um, no, they don't. Please read the article you linked to again. it's 260 characters unless you are using the windows 10 codebase (win10, server 2016 and newer), in which case there's a registry entry that needs to be changed to allow 1024 characters. That's also listed in the article.
How do I know this for certainty? I had to deal with restoring files from a shadow copy this weekend and ran into that multiple times, even after changing to a server that has that tweak applied to it.
Nope you're wrong and you have misread the article. In a previous life I spent 15 years as a data recovery engineer and I wrote the software that we used. I can assure you that any Windows NT derived OS supports \\?\ paths of longer than 260 characters.
MAX_PATH only refers to 'traditional' paths.
As per the text:
"For file I/O, the "\\?\" prefix to a path string tells the Windows APIs to disable all string parsing and to send the string that follows it straight to the file system. For example, if the file system supports large paths and file names, you can exceed the MAX_PATH limits that are otherwise enforced by the Windows APIs. For more information about the normal maximum path limitation, see the previous section Maximum Path Length Limitation."
The text does also say:
"Note that Unicode APIs should be used to make sure the "\\?\" prefix allows you to exceed the MAX_PATH"
That I'm not sure about. I didn't think we upgraded our path handling to Unicode until some time after we started supporting long paths (the earlier DOS and Win16 versions of the tools flattened the output hierarchy and generated a copy script to restore the original paths). But I've found a few other articles that say the same thing so perhaps that's an extra wrinkle that I'd forgotten about.
Update: I just checked the documentation for CreateFileA() and it does say:
"In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode version of the function and prepend "\\?\" to the path."
So I'd obviously forgotten that little detail. To be fair it's been nearly two decades since I last interacted directly with the Windows I/O API or had to concern myself with the size of a character. Given that most people these days are or should be using Unicode strings I think my original post stands but I will slightly modify the advice:
'If you are writing software for Windows with a modern language you can work with paths up to 32,767 characters in length simply by prefixing your path with '\\?\".
If you're still stuck in the dark ages of ANSI strings, YMMV'
:)
That wouldn't work on windows. "*" and "?" are not legal in a path name.
EDIT: nor is newline permitted. And alterring MAX_PATH requires you to hack the registry or group policy.
If it's even there- it's not supported on 2012R2 and earlier.
I blame the userbase for making things like this anonymized example:
X:\dept. supervisors\SITE NAME\jobtitle\display_content\SITE original content\SITE original content\sublocation\old\ approved content use this one only do not use any other files in this folder please V4.xxx
(that's 208 characters using a mapped drive letter, yo.)
It gets even longer if addressing it by the UNC path, which adds the "\\domain.local\dfs\DIVISION" (27 characters) to the front of it, and longer still if you are pulling from a shadow copy, which adds an additional 25 characters worth of time and date stamp of the shadow copy to the middle of the path.
That makes the total path length from the shadow copy exactly 260 characters- You can see where my rage inducement is coming from...
But then, my userbase also does patently stupid things like frequently, and refuses to take instructions on how to organize files in a more meaningful manner...
One particular problem with Linux and the concept of MAX_PATH is it supports a massive range of files systems, from FAT12 floppies to NTFS from the Redmond school, through the ext2-4 set typical of Linux/UNIX, and onwards to systems like ZFS.
Most of those file systems have intrinsic limits due to the on-disk structures!
Furthermore you have symbolic links and the concept of mounting file systems at any named directory in the file system tree that allow a given pathname to traverse multiple different mounted file systems.
But I agree, there ought to be a sane limit that allows easy buffer limit checks and static code profiling.
That's the thing, though. Having a single folder with a well-known path where programs installed system-wide can write their configuration in free-form, human-readable text files, but allowing the configuration to be overridden by a file with the same syntax in the home folder of the user who launched it is just too old-fashioned.
The Registry is a quite clever idea and avoids having thousands of configuration files spread around each one with its incompatible syntax. Far easier to access with a consistent system API, and the application doesn't need to mess with system directories and files to write its own configuration to a known path.
It has been abused with data that do not belong to it - sure - and many bad installers don't remove keys correctly, true as well.
This issue is anyway an ACL issue - it could have happened with the registry or any file holding information that should not be accessible by anybody.
You can't understand what you hate just because it requires you to learn something new since you understood how to use printf().
Meeeow LDS!
Probably you're among those who make the registry a cesspit because never understood how to use it properly.
Ah, so it's not very resilient then?
"Ah, so it's not very resilient then?"
Not in the very early days, no. But Windows has had System Restore, which backs up the Registry at regular intervals plus before Windows driver and update installs, for many, many years now. Windows 10 is the most resilient Windows ever, and often does a great job of self-repair if you ever bung it up badly enough to require that.
"You can't understand what you hate just because it requires you to learn something new since you understood how to use printf()."
This. I've been using / hacking the Registry for the decades it has existed and it is really not all that hard. If the data is user profile-based it most likely, and should be, in HKCU, if the data is not user-specific it should be in HKLM.
The difficulty does increase when you are dealing with the hardware, as class numbers get cross-referenced to one another and you need to sometimes follow the cookie crumbs to find the final location of the data store you need. But otherwise dealing with, and understanding, the Registry is just a matter of learning and understanding the methodology of the data structure concepts.
It wouldn't even be that bad if it was a single cesspit, but it isn't. It's a bunch of cesspits, including different ones for each user profile. But you can still use config files if you want to. Or you can put bits of your config in the registry and bits in actual files. And you can make the paths to your config files dynamic by storing the paths as registry keys. Or you could encode the config file contents and store the actual files as registry keys. Or you could put things in environment variables, which are also kept in the registry, except the registry's copy can be out of sync with the actual environment. Or you could emulate a subset of the registry in a protected space to keep it safe from prying eyes, and then store references to that space in the actual registry. Or you could combine as many or as few of these as you wish.
All of which I've encountered in my relatively short career in IT to date. A single cesspit would at least be one cesspit rather than the recursive infinity of shit that we have now. Unfortunately Microsoft themselves don't stick to using just the registry, so there isn't even a semblance of best practice to try and emulate. Config files seems like the least worst solution to me; the very existence of the registry is an inner platform of the worst possible kind.
'having thousands of configuration files' is generally not an issue for most users as long as they are sensible (e.g. text files that with minimal training can be manually edited). Most users are not going to directly edit them anyway and the few times they might it is relatively easy to do. Plus if the the config file for program X is corrupted only that program is affected ever.
I can modify the config file on Linux for a program. If I am smart and save a copy of the original, working config I can quickly fix any borkage I have done. Bloatware registry is a nasty beast that I am nervous about modifying as I do not know what the side effects are but I know often there are side effects.
PowerShell accesses the registry as a hierarchical object store. Once I understood this, the registry made a lot more sense to me.
And no, I don't think it's more chaotic than strewing configs around /etc, /usr/local/etc, ~, not to mention the wretched /var/lib/<program-name> that some software uses.
Years ago, back in the Windows XP days, I wrote some code to trawl through the directory hierarchy and check that certain ACLs were (still) sane. This came about initially because some ACLs weren't great by default (eg: Everyone: full control on c:\ on, er, Windows nt4? I disremember.). But then it was more that some unpleasant/stupid programs might, and did do, nasty things on install.
One that sticks in my mind was a PCB program that added an Everyone:Full Control ACE to C:\Users\[username] for any user that used it. When I reported it (on eevblog.com forums), the company whinged that it wasn't really their fault, a Delphi library dependency made them do it. Noone was impressed.
I hadn't done this for years because Windows XP and then Windows 7 set some pretty firm and secure defaults for ACLs, at least those used by the OS itself. Which makes this bug a startling regression. If I had to guess, someone didn't know what they were doing and added the ACE to make their code work.
(OT Aside: Interesting that Windows Update is mentioned. A few weeks ago, I found that Update (well, probably BITServ) sends out a HEAD request first before doing a GET. Dicking about with the returned response (as one does and I highly recommend mitmproxy as a transparent proxy for screwing with http responses), I found that setting "Content-Length" to 0 results in Update getting very upset indeed (some sort of infinite loop).
Doesn't happen on Windows 10 though - bah.... If one could fool Update to download an arbitrary exe though, that would be fun...)
I didn't know you could make a path that long! The Linux flaw involves making a *1GB* long file name path (+ 10 bytes, at which point the 10 bytes are outside the buffer but at a known location.)
As for the Windows flaw -- essentially a system makes backups (VSS Shadow Copy) of the password files (security hives), and the backup is readable by normal users. I have found in the past the Windows ACL (Access Control List) system to be overcomplicated, and I think you'll find others who agree. I could be wrong but I'm assuming this problem may have been easier to spot (before it was released) with a less-complicated security system.
Yeah, 'bout that...
KDE PCLinuxOS has been giving me a new kernel about twice a week [ rolling-release, though I am not thrilled with that concept ( personally preferring to re-install every six months ) --- yet it works perfectly ] --- so I think I'm covered.
Plus, with Pale Moon --- xul for the win ! --- it looks exactly like 2012, after which UX and UI unutterably devolved.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
