Slashdot Mirror
Linux's Security Through Obscurity
An anonymous reader writes "The age-old full disclosure debate has been raging again, this time in no other place than at the foundations of the open-source flagship GNU/Linux operating system: within the Linux kernel itself. It beggars belief, but even Linux creator, Linus Torvalds, has advocated against the sort of openness on which Linux has thrived, arguing that security fixes to the kernel should be obscured in changelogs, saying 'If
it's not a very public security issue already, I don't want a simple "git log + grep" to help find it.' Unfortunately, it's not kernel exploit writers who need to grep the changelog in order to find kernel vulnerabilities. On the contrary, it's downstream distributors who rely on changelog information in order to decide when to patch the kernels of their distributions, in order to keep their users safe."
And so the cycle continues.
The thing is that while security through obscurity is a fools game it can also hurt your users to publish exact details of the security vulnerabilities you've found in your own product before many of your users have had a chance to patch the problem.
Linux users typically praise open source software on the basis that vulnerabilities can be found easily and patched by anybody who possesses the knowledge to do so, making open source software more secure. Why should this change now?
He doesn't believe in obfuscating changelogs, just not filling them with security information making it easy to find vulnerable kernels.
It would seem that if the vulnerability is patched in the change log, then it's fixed. I realize that some may need to run on an older kernel, but if a kernel developer found the vulnerability and fixed it, there is little way of knowing if anyone else (read black hat) has already known about it.
When single shines the triple sun, What was sundered and undone, Behold! The two made one! ~Rubbs
As long as the information is in there, isn't it part of their job to read through the changelog, read between the lines, and update appropriately? I have no mercy for the commercial groups that do their own distributions, and quite frankly, if they're going to play with the big boys, anyone who is rolling their own distribution should be put the effort into it to read the changelog for the kernel. It's not like some security hole in a fairly obscure or minor piece of software that they're having to look out for.
The article quote is completely out of context, go read the full thread and see what he really said. His main point is that security bugs are like any other bug. He doesn't see the point in putting code that can trip bugs into the git reports, whether it is a security bug or otherwise.
That said, I don't _plan_ messages or obfuscate them, so "overflow" might well be part of the message just because it simply describes the fix. So I'm not claiming that the messages can never help somebody pinpoint interesting commits to look at, I'm just also not at all interested in doing so reliably.
And from the second email:
> by 'cover up' i meant that even when you know better, you quite
> consciously do *not* report the security impact of said bugs
Yes. Because the only place I consider appropriate is the kernel changelogs, and since those get published with the sources, there is no way I can convince myself that it's a good idea to say "Hey script kiddies, try this" unless it's already very public indeed.
Also, someone is not satisfied with an email from Linus Thorwalds and he drags the discussion over here to /. - This certainly will solve the problem...
(Sorry for RTFA, I should know better)
*snort*
And I thought I'd seen every variant on the usual Slashdot in-jokes.
You win a gold star.
So, what they're saying is when you find/fix a vulnerability you should broadcast on BBC otherwise you will be less safe?
I don't think so. Love it or hate it, obscure security issues do protect some users. Obviously the issues need to tracked and I think changelogs are a good place to do it. There isn't a real reason to inform the world through all channels avaliable. Just fix it, log it, and move on. Anyone who needs to know will know where to look.
This is a an extremely one-sided presentation of this story. Linus makes some controversial but insightful points about the security obsessed culture in the community. This should not have been a "Linus has gone mad" story. This is a legitimate re-evaluation of how security patches are handled.
Read the thread, make your own decision:
http://thread.gmane.org/gmane.linux.kernel/701694/focus=706950
See the Kerneltrap posting which includes a good part of the email discussion.
It looks like Linus' main concern is that publicizing a few bugs as "security" issues will act to hide other real security issues that weren't recognized at fix time; that any effort to publicize security issues will be so incomplete as to be misleading. And I see no mention of these concerns in the linked postings, almost as if the "full disclosure" people posting them are afraid to disclose the potential bugs (which would automatically be security bugs because of the topic) in their own methodologies.
Sounds shady to me.
From here
I have never really seen Linus as a prophet, unlike some, and although I can see the sense in being as open as possible - because that gives developers a strong incentive to fix things - I can also see that it may not be completely stupid to allow developers a bit of time to try to fix a newly discovered security vulnerability. I mean, it is not as if we are talking about keeping things very secret in order to avoid doing anything about it; but most of the time, if the news about a problem isn't bellowed out in public as soon as it is discovered, it buys people just a little bit of valuable time.
But won't fewer be able to take advantage of security vulnerabilities if it becomes harder to decipher changelogs? Security is not an all-or-nothing situation. The fewer people who know about a vulnerability, the fewer that can exploit it, and that means that users have a lower chance of being exploited.
That's actually an important point about security. You cannot make a useful system without any vulnerabilities. You can only maker it harder to exploit the vulnerabilities, meaning that fewer will be able to exploit them. For example, you cannot make an uncrackable and useful code, but you can make a code so hard to break that very few will even try.
What a fool believes, he sees, no wise man has the power to reason away.
Linus, you fought a good fight, but your defeat was inevitable. You were a worthy opponent. WE SALUTE YOU.
Isn't the real problem that you're fighting against market forces which create a demand for the vulnerabilities in the first place?
That benefit isn't as great as the benefit of OSS I think...
But consider what could happen if all the software for a voting machine were out in the open. Doubtless there would be those who might find a bug, and keep it to themselves in the hopes of using it to elect who they want. I'm not saying the current situation is better, because I think it's worse, but if the voting software were OS'd we might just be out of the frying pan and into the fire.
IANAP so maybe someone else can offer a technical solution for how to let the code be OS'd, yet keep it from being readily exploitable if a bug is found. Think of the money you could make betting on your presidential candidate...
In the old argument, freedom requires responsibility, this is a prime example of the conflict.
In a truly freedom based model, you assume and rely on the fact that Linux users are responsible for their systems, and thus WARNING SECURITY BUG FIX NOW is a good title to an important patch.
In the less free "sharecropper" future of Linux where user's rely on upstream vendors to "take care of them" and take no responsibility for their systems, hiding such warning is great security theater to make them feel more secure. They are not more secure, we all know, but they FEEL that they are and the kernel guys pretend to act more responsibly in this "post 9-11" fear based world.
Its all bullshit and everyone who knows anything knows it. What surprised me was Vixie just saying "patch and trust us" without explaining, with specificity, why.
When even the proponents of freedom start to fear freedom, we are in deep shit.
Since when did distributions rely on grep to find out about security problems?
There are upstream security mailing lists where security problems are disclosed to the various distributions security teams for most projects (and probably including the Linux kernel), so they probably know about these problems before they are even fixed to begin with.
unless the security bugs are malicious and in on purpose... they're just bugs by my definition.
http://thread.gmane.org/gmane.linux.kernel/706950
I think the OpenBSD crowd is a bunch of masturbating monkeys, in
that they make such a big deal about concentrating on security to the
point where they pretty much admit that nothing else matters to them.
god n. : the Supreme Being, indistinguishable from a good random number generator.
The more demand for commercial support, the cheaper it will become. That means that eventually the cost to support university Linux-based systems via RedHat, Novell, etc. may become cheaper than the cost of keeping people on staff to do it. The end result is that while the universities may not be doing it for themselves anymore, it's cheaper for them to focus on what they do best. After all, no one seriously argues that society is worse off today because the average car owner cannot rebuild their car like a mechanic.
But I've already started compiling a book of his wisdom and am preparing to start a church! Oh well, guess any good religion needs an enemy.
Read this post to get some perspective:
http://article.gmane.org/gmane.linux.kernel/707044
Linus is being blunt, as usual, and he's telling everybody what his personal policy is towards disclosure. If he finds a bug, he fixes it, and he doesn't rate security bugs as more or less important than other bugs because he's a kernel hacker, and therefore security bugs are not his sole focus in life. He doesn't use any special language to highlight or obscure security fixes in the changelog, he just describes the fix, which is what people are claiming is "security by obscurity".
From that, people looking for something to bitch about have created this kerfuffle; it is a tale told by an idiot, full of storm and fury, and signifying... nothing.(from Macbeth, 5.5)
"Shakespeare really kicks the cap off" -- James Hovenac
I am considering moving back to Vista, I have a pretty plain install of Ubuntu but almost daily there are a least 4 or more security updates that need to be installed. Then the system usually requires a reboot for the updates to take effect.
Heck, at least Microsoft is only one Tuesday a month and you get them all at once.
Season 2, Episode 6.26
"The fight for freedom has only just begun." - Geert Wilders
I think what pageexec (the "antagonist" in the referenced thread) was trying to say was that he feels a lot of the developers don't follow Documentation/SecurityBugs in their commits in a consistent way. He's saying that when people post commits for regular bugs, they include a decent amount of data about what they fixed, but if it's a security bug, people are posting a minimal amount in their commits. Apparently in Documentation/SecurityBugs, it says that full disclosure is the policy, but what he's seeing is less than full disclosure in practice. That is what the thread is actually about, Linus' opinions are ancillary to that point.
He's just saying that it seems to him that what is written as policy for kernel devs is not what they're actually doing, so they should either change the policy or change their commits. If the changelogs don't conform to policy, at some point somewhere downstream devs are going to miss something because the policy doesn't match the practice, and that's what's a security risk.
"so guys (meaning not only Greg but Andrew, Linus, et al.), when will you publicly explain why you're covering up security impact of bugs", pagee...@freemail.hu
"I don't cover them up", Torvalds
"by 'cover up' i meant that even when you know better, you quite consciously do *not* report the security impact of said bugs", pagee...@freemail.hu
"Yes. Because the only place I consider appropriate is the kernel changelogs, and since those get published with the sources, there is no way I can convince myself that it's a good idea to say "Hey script kiddies, try this" unless it's already very public indeed", Torvalds
"one reason I refuse to bother with the whole security circus is that I think it glorifies - and thus encourages - the wrong behavior It makes "heroes" out of security people, as if the people who don't just fix normal bugs aren't as important", Torvalds
"I refuse to have anything to even _do_ with organizations like vendor-sec that I think is a corrupt cluster-fuck of people who just want to cover their own ass", Torvalds
http://tinyurl.com/5qyon3
http://groups.google.co.uk/group/fa.linux.kernel/browse_thread/thread/5bdf2e1b8a90142c/abcf79768bb7ce7f?hl=en&lnk=st&q=#abcf79768bb7ce7f
davecb5620@gmail.com
This, in my view, is total nonsense, if you don't mand me saying so, CmdrTaco. The full source is out there for anyone to see, bugs are reported in the kernel mailing list, for anyone to see. How is this in any way shape or form 'security through obscurity'
davecb5620@gmail.com
I knew it couldn't last. Oh well. There is always FreeBSD.
I am very small, utmostly microscopic.
I think the point is that obscurity does not hurt security. On its own, it cannot substitute for actual security measures, but it doesn't DECREASE the security of a system. (If somebody can think of a counterexample I want to hear it!)
The problem is that not everybody can upgrade right away. The issue might have been fixed in version X.Y.Z but still exists in version X.Y.Z-1. Certainly you should fix the issue, but clearly explaining what it is will only cause harm to people still running X.Y.Z-1.
corrected headline .. :)
davecb5620@gmail.com
Well for one thing, Linux is being installed on more and more consumer PCs these days. Most of the UMPCs out there run some sort of Linux, as does every $200 PC sold at Walmart. You can't expect all the people buying these computers to know anything about how to patch a kernel. If Linux is to be accepted, it needs to be easy to use, and recompiling a kernel is not something the average user should ever have to do. If you want to keep Linux for the nerds, that's fine, but then don't complain about Microsoft and Apple when their OSs are not to your liking (not that you personally have done so).
Eggs
Milk
Bread
Cat Litter
Soda
Having had this (and other similar) conversations follow through LWN.net, LKML and various other places that just won't let me escape it, all I can do is express surprise that the article wasn't "Sponsored by PaXTeam".
Similar arguments keep getting raised by various people affiliated with that name and again and again they just don't listen. It took weeks to get them to bring up such problems in a proper, public forum and now they are just shouting for nothing more than attention.
Nobody cares, because they can't be bothered to 1) listen. 2) Use appropriate forums. 3) Express alternatives 4) Take no for an answer. I tired of the arguments on LWN, and increasingly I'm getting tired of visiting websites/forums/mailing lists where the same people are starting the same arguments again.
If you're worried about security, keep your software updated. You WILL hear about anything REALLY important. If you don't keep it updated, that's much more of a problem than anything else.
If we say that obfuscation is necessary because one doesn't want the info to fall in the wrong hands, what's the root-problem then?
a. the fact that the info exists
b. the fact that the info is presented on a silver platter to the wrong people
c. the fact that not everyone does a timely update
Obfuscation deals with a & b, can we replace it by offering a solution for c ? Maybe one could suggest a fundamental change in the way updates are made instead of how they are presented?
"Violence is the last refuge of the competent, and, generally, the first refuge of the incompetent" - Thing_1
The problem is the bogus presumption that there is a class of bugs called "security bugs", and that fixing these bugs is somehow more important than other bugs.
This, in turn, is based upon the PHB contempt for "hackers", and the assumption that "hackers are always changing things for no good reason"; leading to mechanisms to prevent updates from being installed in the name of "keeping the system stable." Far more harm has been caused by this PHB mindset that has ever been caused by bugs in new code.
When a developer has updates, he has already triaged them into "get into the field now" (what he releases) and "can wait a while" (what is in his development sources). What the PHBs, and sadly some ./ers, want is for the developer to do additional triaging of his release updates.
This is unreasonable. It requires the developer to anticipate the interaction of a potentially unbounded set of combinations of updates vs. non-updates. Perhaps there is no security problem with bug A, or bug B, or bug C discovered at different times; but there is a security problem if all three are unfixed. Or perhaps fixing bug C without fixing bug A months earlier introduces a security problem.
Now, with this said; the release version should always have all known critical issues (not necessarily security) fixed. Nobody should ever be made to install a "current release" with known critical issues. This means that the "current release" must be updated as needed to preserve this state.
The Redhats of the world are in the business of backporting some fixed into ancient releases in order to satisfy the PHBs. They make their money by doing that, and charge handsomely for it. I haven't heard of anyone paying Linus (nor, for that matter, most other developers) to provide that type of service. If you want such services, write your checks to Redhat. Don't expect developers to give it to you for free.
If you read the seclists article (the second link), Mr. Spengler points out the following:
The Linux kernel has a formal policy in Documentation/SecurityBugs which
states under Section 2 Disclosure:
"We prefer to fully disclose the bug as soon as possible."
To the extent that this policy does exist, then Linus' position of 'they're just bugs' is clearly a problem. I don't see how you can treat them as 'regular bugs' and still have any hope of full disclosure. Put another way, if no one sees a problem with Linus' way of doing things, then it is simply untrue that Linux has a full disclosure policy.
The FA claim of "security by obscurity" seems a little much, IMO. It seems we're not talking about intentionally hiding security problems as much as lax adherence to the full disclosure policy.
That was definitely scary reading...
It's hopeless - security in Linux sucks.
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
It's tolerable that you don't read TFA, but at least read TF comments. The article itself is misquoting Linus.
Otherwise, ask yourself why it takes less than 5 minutes to pwn a Windows computer, but it takes nearly forever to pwn a Linux computer. It's not Linux security that sucks. It's your Redmond-brainwashed mind.
It is refreshing to still have some real humans among us, who do not need to carefully avoid touching corporate interests when it comes to expressing a personal opinion. The open source community needs to be told the straight truth from time to time, and personally I would not be offended if he would have used the same words to criticize my own work. Actually, I would have fun imagining myself being part of a group of masturbating monkeys. :-)
While we should try to talk friendly to users, a bit of humor and stronger expressions are the urgently needed salt'n peppa in a decent conversation between developers.
The IT security industry was always sick, but it managed to gain much more importance recently, because the world felt into a period of stupid fear some years ago. I really hope some day we can start to do constructive and serious security based on proven risk management principles and facts again.
What's feeding my wallet, is often not right, though.
Greetings,
Chris
"An operating system must operate."
Most all the distros offer their preferred patched kernel versions. Usually a distro release will be based on a specific kernel iteration, which will then have any security patches back-ported to it. The distro users have ways to check for security notices - and should, on the whole distro, not just the kernel.
Each distro's kernel team should be tracking all patches to the kernel, for all bugs, since even non-security bugs may crash other packages in the distro. They should know enough to spot the fixes that are security-urgent. So for normal users of normal distros using those distros' kernels and tracking those distros' security notices, all of this is a nonissue.
If you're rolling your own Linux, it there's a point to complaining that kernel security bugs aren't flagged. On the other hand, if you're doing this as something other than a hobby, you should either have your own kernel team, be an expert yourself, or switch to running one of the standard distros, where - if the distro team is any good - all this is taken care of.
"with their freedom lost all virtue lose" - Milton
How is schneier.com trolling? Because the poster linked to his discussion of full disclosure from 2001?! And "harsh words for BSD" is definately trying to be nice to your lord linus. He outright flames openbsd calling them "masterbating monkies" because he claims they make too big a deal out of security. This despite the fact that he has never tried openbsd, has never spoken to the openbsd developers, and all because they happen to embrace full disclosure. OpenBSD considers correctness to be important, and security is a side effect of correctness. They agree with linus that all bugs are important and need to be fixed. They just happen to think its important to let their users know when there's a potential security hole that could affect them. Linus is an ignorant troll.
I don't believe that vulnerability fixes should be cryptic in the changelog. For one as stated before it helps distributions patch and fix their kernels for the end-user. It also would make it a big hassle for more technical users who patch their own kernel. The 'security through obscurity' way of disclosing vulnerabilities has been debunked several times. It's counter-productive against the very openness of Linux.
Folks, it's not an OMG!!! THEY HID THE BUG AND NOW WE'RE GOING TO DIE!!! issue.
Security through obscurity, for those who remember the olden days, meant not disclosing code, not revealing algorithms, and relying on enforced ignorance on the part of the user/exploiter.
This ain't it. The code is there. The comments are there. Anyone can find it. What Linus is talking about is failing to aid and abet hackers in their attempts. It is simply not ACTIVELY ADVERTISING exploitable code. This is something that seems remarkably sensible.
Unfortunately, anything less "open" than having a courier deliver working exploit code to hackers is labeled "security through obscurity OMFG!!!" by idiots.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Controversial indeed.... Linus might be mad, but maby of his comments are +5 Funny
We all practice some security through obscurity, we keep our passwords to ourselves, filter our actions versus our moral code and we keep our clothes on while in public. When it comes to our children, we try to strenghten their moral code so they don't run around naked and easily exploitable while realizing that a chastity belt or locking them in their rooms would be a bit excessive. We try to teach them to chose their social networking links carefully. If they chose to learn the martial arts, all the better.
Everyone we meet growing up and getting old contributes to our code, but each person is still in control of what is accepted, compiled in and run as a process. Every parent and sysadmin are but in partial control of the input/output, but we can't monitor and control everything lest we forment rebellion that is dangerously self-destructive. So best you can hope for is to control what you can reasonably, lead by example while accepting your may not be the leader they are looking to all the time and monitor judiciously the developement.
Mod parent insightful!
Have you driven a fnord... lately?
You must wait a little bit before using this resource; please try again later.
Obscurity: Bad
Security: Good
Obscurity+Security: Even better
No sig today...
Probably will get lost in the masses, but I would just like to point out that Linus' OTHER point is that he doesn't want to tag patches as [SECURITY] or some such because the submitter (and the reviewer, etc...) of the patch does not necessarily know whether it has security implications or not. What this means is there would then be all the tagged security patches (which downstream maintainers would presumably prioritize) and then there would be all the untagged security patches which would be even more likely to be missed because maintainers would be relying on the security tag.
Another issue that was pointed out, acknowledged, and then subsequently ignored in the LKML thread was that "software development and security evaluation are separate skill-sets". This whole thing looks like a PR stunt to me. (on the part of "PaX Team" to be clear)
On the other hand, if there were a security-minded group of individuals who felt that this enhanced level of "full disclosure" is necessary, they are perfectly free to review all the PUBLICLY AVAILABLE patches and publish which ones they deem to address security vulnerabilities.
I give extra short-shrift to people like this who are arguing for someone else to do work on their behalf.
This isn't "security through obscurity". it's reasonable disclosure, mainly to give some time to create, distribute and apply a fix
the methods are open to discussion, and might not be the best advice (or may be, i don't know). but just picking a catchphrase and running around is just bad journalism.
-Kz-
"On the contrary, it's downstream distributors who rely on changelog information in order to decide when to patch the kernels of their distributions, in order to keep their users safe."
No, it really isn't. No responsible kernel maintainer would rely solely on changelogs for information.
Most of the controversy is totally misplaced. This is essentially about having
* SECUIRTY ISSUE: fix info
vs.
* fix info
Is that really obscurity?
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
" there has traditionally been an unwritten rule among security professionals that the discoverer of a security vulnerability has an obligation to give the vendor an opportunity to correct the vulnerability before publicly disclosing it."
http://www.microsoft.com/technet/Security/bulletin/policy.mspx
I swear I didn't know it was loaded...
... then troll with something that can't be trivially disproven by checking the changelog. There have been six kernel updates for Hardy released since mid-April, when it was released, which comes out an average of roughly one every two weeks. Not all updates are security-related. Non-kernel updates don't require a reboot.
Don't know what you're talking about. Linux has been on my desktop since 1996...
Bow-ties are cool.
Read the many replies to this idea already. Linus is not actually promoting security through obscurity, he is advocating treating security bugs like any other bug, and not posting PoC in the logs.
Your desktop != The year of Linux on the desktop
Linux is on the desktop. What more do we need?
Bow-ties are cool.
I spent four hours reading this and thank you for posting this. As someone unfamiliar in computer security, the ideas I got were:
1. Full Disclosure is the norm in the computer security world today and has empirically been shown to improve security much more than bug secrecy.
2.. An idea of why FreeBSD and OpenBSD are considered more secure. It seems that basically there is a direct correlation between the rate of change in the code and security holes, as writing new code and changing code leads to mistakes and fixing security holes is always post-facto.
3. It seems like given a particular security hole, it is quite possible for an exploit to gain control sufficiently enough to watch over what I do, what files I open, what my network traffic is, etc, scary etc. This is actually quite scary.
4. I didn't know the security industry was huge, and there are plenty of well-paid, full-time programmers looking for exploits.
Given the above fact, that each found (and who knows, how many unfound) exploit can lead to not trusting my own computer, I would rather prefer that everything is open and well-known, with a reasonable window of secrecy. Especially since it is seems very easy for kernel developers to make mistakes while coding fast (they are human after all, doing a tough human endeavor, they are not any kind of gods). It is better that they make life easy for the good guys, since the well-paid bad guys are going to find out anyway.
Why don't the kernel developers spend time fooling the business folk instead of us? It is easier to pull wool over their eyes technically anyway. Or best of all, why not just tell the truth?
spender and PaxTeam are obviously very experienced and no one seems to have a proper, head-to-head rebuttal to them, other than FUD. I wonder why?
And maybe it is just me, or do some of the comments posted above seem to want to distract my attention? This is getting scarier.
cisco
My rights don't end where your feelings begin.
What you're missing though is that the majority of Linux systems are embedded systems: phones, point-of-sale terminals, etc etc. Most of the users of these devices don't know that the machine runs Linux and don't know how to go about patching. Rolling out patches to these is not at all easy.
Engineering is the art of compromise.
1) Inflation is a big factor.
2) OPEC
3) Most of the world's oil supply is controlled by foreign governments.
I had a BSD box for 4 years at a hosting service.
Technically without HW maintenance, and almost no upgrades. That includes web software updates, which lead to various old wordpress, postnuke, phpbb attacks.
While from time to time these attack succeeded to change the index page or do some stuff, they never actually succeeded to install any root kit, spam bot or do similar damage.
Why ? Because all the code was compiled for Linux, and even after successfully exploiting bad web programs they were called from the temp dirs : THEY DID NOT RUN. that is a prime example of security through obscurity....
Now is it really safe : no, but it luckily protected the server against these attacks, and probably the not so obscure Linux boxes fell....
Just my 2c ... Obscurity should not be used for security, but if you ask me if I wanted a car alarm EVERY ONE has, or one that NO ONE HAS, I go with the latter.....
what is open source.....
community contribution?
security bugfix?
an eagle eye of cracker?
if u want something to be as stable as u wish....u need to invest by yourself...maybe in terms of money, maybe in terms of skill....
but not nothing
just roaring to developers is meaningless...u can choose not to use it.....as long as u don't feel comfortable....
but when u get on the train....u r not babysitted...be prepared...
Security updates for whatever apps you have installed on your Windows machine aren't rolled out with minimal intervention on your part--you have to stay abreast of notifications from a variety of vendors. You see more updates for Ubuntu because the distribution aggregates updates across all of those vendors.
If you really want to, you can only apply the updates once every month, on a Tuesday, if it would make you feel better. I don't understand why you'd want to do this, but you'd then be able to replicate the joys of Patch Tuesday and the attendant month-long wait until vulnerabilities discovered on Wednesday are patched.
...to pay your $699 licensing fee you cock smoking teabaggers!