Forgot your password?
typodupeerror

Comment: Re:de Raadt (Score 1) 286

by rev0lt (#46773755) Attached to: OpenBSD Team Cleaning Up OpenSSL

That they have an OpenBSD appliance somewhere in the rack doesn't protect them.

Well, that depends. Following your assumptions on wide generalization of setups, it is common to have dedicated servers working as SSL proxies. Again, I'd be surprised if at least some of those companies weren't using OpenBSD for that. Or some vendor that leveraged BSD tech in their product.

I'm assuming that there are so few that the probability of OpenBSD servers being the first round of exploits--or really in any significant way exploited early enough that the bug is exposed and understood before the damage is probably done

You cannot assume that.You don't know how long this vulnerability has been exploited, and it is reasonable to expect that some high-profile targets that use OpenBSD in their stack may have been compromised. Its not only about how OpenBSD could have mitigated this - its about why a decade goes by and basic security measures are still the exception in other operating systems.

You mean like with object pooling, which is essentially what freelists are?

AFAIK the problem isn't "trying to optimize thousands of a-couple-of-bytes" allocation hashes. Even if it was, it is a good idea to cleanup free blocks with zeros. If you're allocating a 4k page, you probably should use other mechanisms. The problem is, on top of the fact that no boundary check was performed on a copy operation, this passed a code review and was incorporated in the most widely used SSL library, that reads and process sensitive information.

It's a common design pattern. Next you'll tell me Duff's Device is a dumb idea.

When applied to modern unix computing? It is. You can have a smart design around it, but as it is - its dumb as fuck. Eg. acessing odd memory positions is a stall in most modern CISC cpu's (and some ancient ones too), so your code will actually run slower. In some cpu's, the stall is everything that is not 16-byte aligned. In the end, if you're using C and trying to be clever in the architecture, either you're doing critical kernel stuff or you should be using assembly anyway. Odds are, your very clever algorithm implementation will be a pile of poo on a newer generation of cpus and no compiler will save you from that (have a look at the Bresenham's integer line drawing algorithm for an example).

I had a memory allocator project 10 years ago that I abandoned which aimed for better memory density and high security by abandoning brk() and using mmap() and thread/class grouping (allocations from the same thread tend to allocate/free together; allocation fragmentation can be dealt with by grouping allocations of a given size together in a range of memory, rather than just buddy allocating in one big open field), and used all kinds of tests with canaries and dtags (deleted! double-free!) and other security bits.

That actually sounds interesting. What happened to it?

I got in an argument with Theo some 8 or 10 years ago about static checkers. He told me, rather loudly, that static checkers make programmers lazy because they start just writing to satisfy the checker and then get sloppy with actual code review

I'm a big fan of static analysis, but I do understand his point. Having these features available on development time do take a toll on the quality of the code. Having them available on a CI server or whatever is a very good idea. If an error is triggered, proper atention will be given to it, instead of having someone just changing the code so it stops complaining about the error.

His strong position was that static checkers INCREASE defects in code; but I see that somewhere in the past 5 years he's reversed that position sharply.

He probably tried using one :D

Comment: Re:de Raadt (Score 3, Interesting) 286

by rev0lt (#46761233) Attached to: OpenBSD Team Cleaning Up OpenSSL

OpenBSD is a hobby OS

*every* community-driven operating system is a hobby OS. Is that relevant?

It's like Linux with grsecurity

Maybe for you. Not for me. And it is actually easier to audit and it has a smaller kernel. And a kernel debugger. Something that is quite handy to find and troubleshoot problems.

(...) I would avoid the bet.

There are also more Windows machines than *nix machines with an internet connection. Some little-known RTOS are way more popular than Linux and BSD combined. Your point is?

OpenBSD's allocator is what we call "Proof of Concept".

Monolythic kernels are a proof of concept of monolythic designs. Every existing implementation of something is a proof of concept of the given concept. Again, what is the point?

It exists somewhere in real life, you can leverage it (I've leveraged proof-of-concept exploit code from Bugtraq in actual exploit kits), but it's not this ubiquitous thing that's out there enough to have an impact on the real world.

While OpenBSD itself is a niche product, its team is very well known for producing hugely popular products, including OpenSSH and PF. BSD server usage is low, but there are no real stats on middleware - routers, storage units, set-top boxes, closed devices, etc. FreeBSD is reportedly used in Playstation - that's more users than most Linux distros has. Is popularity usage relevant to the discussion? Not really.

Suntrust, Bank of America, slashdot, the NSA, Verisign, Microsoft, Google--is running a non-OpenBSD operating system with no such protections

I'd actually be very surprised if none of these companies use OpenBSD goodies - Either OpenBSD by itself, or middleware BSD products. And then you can add to this OpenSSH, OpenBGPD and a couple more interesting products. Microsoft used OpenBSD as a basis for the Microsoft Services for Unix. But again - is it relevant to the discussion? Not really.

And again, the concept of allocation caching is common. Freelists are used when allocations are all the same size; that gripe is essentially that a valid data object is not valid because they dislike it. Plenty of software uses freelists, and freelists are a generalization of the object pool software design pattern used for database connection caching in ORMs, token caching in security systems, and network buffers (ring buffer...). I would be surprised if OpenBSD's libc and kernel didn't make use of freelists or object pools somewhere.

So, you're saying that optimizing memory allocation in privileged space is the same as optimizing memory allocation on a userland library? That managing fixed-sized, out-of-the-userspace-address-pool structures is the same as trying to be smarter than the local malloc implementation? No system is perfect, but it generally sounds like a very bad idea.

In short: there's a lot of whanging on that OpenSSL made OpenBSD's security allocator feature go away, and that (implication) if OpenSSL had not done that, then an exploit attempt would have come across one of the 0.01% of interesting servers running OpenBSD, and a child Apache process would have crashed, and some alarms would have gone off, and someone would have looked into the logs despite the server humming along just fine as if nothing had happened, and they would have seen the crash, and investigated it with a debugger, and then reproduced the crash by somehow magically divining what just happened, and done so BEFORE THE WHOLE WORLD HAD DEPLOYED OPENSSL 1.0.1.

So, you're assuming there aren't compromised OpenBSD servers because of this. And that no one actually tried to exploit it in OpenBSD. The fact is that no one kows exactly the extent of the damage of this vulnerability, or if it could have been detected way earlier by using OpenBSD or Linux with grsecurity or whatnot. And it still remains a fact that it is a dumb idea to try to micro-manage memory on your library.

Maybe you should whine that everyone else should do similar exploit mitigation techniques to OpenBSD first, instead of whining that OpenBSD could, in theory, possibly, have caught this if it was less-broken.

Actually, the whining I read was precisely that - why aren't OS developers doing the best they can to avoid and mitigate these kind of errors? And if a hobby OS like OpenBSD can do it . and has done it years ago - why isn't this kind of protection mainstream?

Coverity missed it even with the freelist disabled; Frama-C would not shut up about Heartbleed, and should have detected this ages ago. So nobody ran Frama-C against OpenSSL. Apparently a static checker could find Heartbleed on a whim, and could find it even if it wasn't being exploited--which means it could find it faster than OpenBSD's allocator

That only demonstrates that someone needs to take a serious look at what's going on with OpenSSL and start fixing stuff. Oddly enough, its the hobby-os-that-no-one-uses that is picking up the task - by THEMSELVES. Theo does have a loudmouth, but they are actually trying to improve it. How many companies would benefit from that? And how many of those have started doing it? Yeah...

Comment: It depends (Score 1) 119

I've seen advantages and disadvantages in both scenarios. It depends on the application and the profile of your production systems. As a rule of thumb, your test/dev systems should be as close as possible to the production machines; If you're deploying to cloud services, you should have your test and staging system running on the same platform/provider; If you're deploying to bare metal, you should have dedicated servers for testing and staging. The applications don't work by themselves, and eg. controller/driver problems in production systems are quite difficult to diagnose if you can't replicate the problem in staging; So it doesn't really make sense to test something on a cloud provider (with "emulated" hardware) if you may be needing to be on the lookout for specific problems on your own hardware. There is also the question of I/O - both local and network. Dedicated gear will always be faster than virtualized solutions, or at least cheaper for the same amount of IOPs. If you have an application that requires heavy I/O, usually cloud services are almost as expensive as they are useless. As an example, you can rent a couple of servers in Hetzner that will run *laps* around most EC2 instances, for a fraction of the price. Since usually test data is ephemeral, server reliability isn't really an issue - a competent Sysadmin team will provision a cluster of those by a fraction of the price of a cloud service. So, in short, if using cloud in production, its the wise move, if not its probably not what you're looking for.

Comment: Re:US Law (Score 1) 91

by rev0lt (#46629027) Attached to: Book Review: Money: The Unauthorized Biography

it's printed right on the money: "This note is legal tender for all debts, public and private". You're legally required to accept US Currency. It's up to you how much, but if you have a debt you don't get to say no. You can require that the currency be in certain denominations (e.g. you can decline a jar full of 10,000 pennies) but that's about it.

Someone already replied to this. And, as you may have guessed by now, the US didn't invent the concept of money (or markets, for what it's worth).

If you say no and it's enough money to go to court over than sooner or later a judge is going to make you take the money. If you tell a judge no he throws you in prison for contempt of court.

This is just silly. A judge CANNOT FORCE anyone to do anything. The judge has no power. The institution the judge represents is a different matter altogether. But, as an example, I can easily create a pizza restaurant that works exclusively via subscription and is payed via electronic transaction. AFAIK there is no law against this.

Oh, gold's intrinsic value is that rich people like to wear it.

You don't mean rich, you mean wealthy. And if they're wealthy, you probably already have gold, or some spare stuff you can trade from/to gold - thats WHY they're wealthy. And part of it is, people like yourself see a demand for gold (because rich people want it...), so will gladly accept it as currency, thus giving it its intrinsic value. You would work for gold :)

Comment: Re:What a bunch of hooye, total garbage (Score 2, Interesting) 91

by rev0lt (#46625365) Attached to: Book Review: Money: The Unauthorized Biography

however real money

There is no real money. Its a trust system. You have only perception of value.

as in money that is not fiat

There is no real money. Its a trust system. You have only perception of value.

namely gold stood in the way of governments

Gold has no intrinsic value by itself. Its a rare metal. Its not money. Its perceived value is not even stable across time. Again, its a rare metal in a trust system. Gold has value for you because you can exchange it for stuff you actually need. Other people accept it exactly because of the same motive. Oddly enough, if gold was rated at production cost, would probably be way cheaper today than it was 150 years ago (you know, before combustion engines and dynamite and TNT). Why people like gold so much? Its a noble metal, shiny and it doesn't oxidate. What's not to like?

In any case, governments have no legitimate role in money manipulation

You mean, the same governments that actually LEGISLATE about what and how the currency system works, and how, how much and how far transactions will be taxed?

Keynes was not an economist, he was a charlatan

It may be the case, but because even a 4th grader can dismantle your arguments, I'd take your opinion with a grain of salt.

you do need to understand what money is

Apparently you feel lonely. I'd suggest you'd start with the basics.

Comment: Re:I guess Minecraft will stop using it (Score 1) 115

by rev0lt (#46609065) Attached to: Facebook To Begin Deploying Btrfs

And to top if off, I dislike Zuckerberg intensely as a person, have no respect for him,

So. these sound like personal feelings and not a rational evaluation; I',m fine with that, but its not really a valid argument. And regarding Facebok, I'd be really surprised if Zuckerberg had any kind of real control over the company.

here is the service, run it on your own servers, and we'll sell you support.

You realize that, without a centralized system, the social model would not exist, right?

Not the brand, but what the tool is and does. Is it a secure two way messenger that I have complete control over?

Its not. It's more of a 2-way p2p messaging system. And I'd take skype proprietary encryption over any SIP-based hardware device. I'd really doubt that what you describe even exists. And even if it did, you could not prove it. You cannot prove security, you can only disprove it. You can demonstrate its secure by lack of proof otherwise, but it is a play with words. Having the source code adds almost nothing to this, except you get the "illusion of control". Do you really check every detail, every line of code? And I'm assuming you're aware of the algorithmic complexity of some of the crypto code out there; even fully transparent projects like openssh have bugs now and then.

Or is it is an insecure system hosted by a 3rd party who actively monitors everything I do with it to try and profile me?

Every system on the internet is potentially insecure. Your dedicated server may have hardware backdoors installed. Your crypto software may be leaking details. Your CPU may be flawed in specific computations. The fact is, you control very little on a modern stack. And don't even get me started on communication channels...

The only reason I still use it is because I find the voice quality, and call connection reliability to be higher than the alternatives I've tried, the ease of having multiple 'group chats' in progress, and the seamless ability to jump from group chat to group voice. If I could find something else that did it better and had a business model I liked more, I'd switch

Well, you can do it easily with both SIP over VPN or IAX2, and Asterisk. And the available stack is fully opensource, and you can run it on your own server. Now you just need to convince people to use your server and install all the required software for it.

Comment: Re:I guess Minecraft will stop using it (Score 1) 115

by rev0lt (#46600855) Attached to: Facebook To Begin Deploying Btrfs

Meh, I'd still rather it be whatsapp than facebook. I perceived them to be much smaller, even if still fairly big.

I understand that feeling. But its not based on facts or even objective... People often perceive big companies as "evil", and forget that, in that regard, all companies are evil in some way or another.

But for what its worth I've never had a whatsapp account nor an instagram one, nor a facebook one. I find nearly all internet "social" to be a monumental waste of time bundled with massive privacy invasion and avoid it pretty thoroughly.

Well, I had a whatsapp account and a facebook account. While I tend to agree regarding the waste of time, it is also a way for me to connect with friends and colleagues from past companies, and often discuss technical stuff and what's happening in the world. Isolation is good often, but its not good always. And while you can connect in real life, is quite hard to keep track of friends when they're scattered a bit all over the world.

I do have a skype account though, and would love to find an alternative to that too. Because the ads bug me, and the attachment now to microsoft bugs me.

A tool is a tool. What matters which brand produces it? Again, the "big" company stigma... :)

Comment: Re:I guess Minecraft will stop using it (Score 1) 115

by rev0lt (#46598291) Attached to: Facebook To Begin Deploying Btrfs
Well, I'm no expert, so take what I'm about to say with a grain of salt, but Whatsapp would never be profitable as a standalone company with their current business model. And what you call pretty limited, its not when cross-referenced with eg. your cellphone number (Facebook, Google and VK all "encourage" you to give this). For many people, a cellphone number is way more stable than a facebook profile. And whatsapp (either the app or the server) keeps full blown logs of all conversations, so its quite easy to mine them for keywords, phone numbers, places, urls and pictures.

Comment: Re: Why are they posting old source code? (Score 1) 224

by rev0lt (#46579973) Attached to: Microsoft Posts Source Code For MS-DOS and Word For Windows
Did you even read what I wrote? Aside from cmd.exe (which may or MAY NOT include some command.com funcionality - probably not, command.com source was a bit messy), everything else is not even remotely DOS-related, but an ABI. BTW, most of MSDOS 6.2 code is still assembly, and that makes it "unmaintainable" by today standards.

"Only the hypocrite is really rotten to the core." -- Hannah Arendt.

Working...