Linked by Dareka on Fri 19th Apr 2013 10:40 UTC
BeOS & Derivatives "Starting with hrev45522, address space layout randomization (ASLR) and data execution prevention (DEP) are available in Haiku. These two features, which have actually become a standard in any modern OS, make it much harder to exploit any vulnerability that may be present in an application running on Haiku, thus generally improving system security."
Order by: Score:
In the sidebar?
by chekr on Fri 19th Apr 2013 10:46 UTC
chekr
Member since:
2005-11-05

Now this is some real interesting news, about an actual OS, but on OS News it is relegated to the side column?

Reply Score: 3

RE: In the sidebar?
by WereCatf on Fri 19th Apr 2013 10:57 UTC in reply to "In the sidebar?"
WereCatf Member since:
2006-02-15

Now this is some real interesting news, about an actual OS, but on OS News it is relegated to the side column?


Well, how much is there to write about it? There isn't much interesting in the implementation details and sure, Thom could've written in length what ASLR and DEP are and how they function, but.. well, that wouldn't really been relevant any longer.

Reply Score: 2

RE[2]: In the sidebar?
by some1 on Fri 19th Apr 2013 14:07 UTC in reply to "RE: In the sidebar?"
some1 Member since:
2010-10-05

Well, how much is there to write about it?

A fair bit, actually. DEP and ASLR are not binary "on/off" features, there are many details to what they actually do in the specific implementation and deployment.

Reply Score: 4

RE: In the sidebar?
by Thom_Holwerda on Fri 19th Apr 2013 11:07 UTC in reply to "In the sidebar?"
Thom_Holwerda Member since:
2005-06-29

As the comment above already notes - what's there to write?

Reply Score: 2

RE: In the sidebar?
by bassbeast on Sun 21st Apr 2013 00:14 UTC in reply to "In the sidebar?"
bassbeast Member since:
2007-11-11

Uhhh...how EXACTLY is this interesting? ASLR and DEP are fine and dandy for OSes that are being actively targeted but for haiku this is as useless as tits on a boar hog as we say down here.

So if you are happy they have that checkbox on a bulletpoint? Then I'm happy for you, I really am. But I bet you could scan the web for the next year and not find a virus targeting haiku that ASLR and DEP would protect against, hell you'd be lucky to find a single bug that would run on it at all.

Sometimes security by obscurity actually does work and unless they have made a deal with some OEM to sell haiku boxes I don't really see a point in this other than filling in a checkbox on a list, i really don't.

Reply Score: 2

RE[2]: In the sidebar?
by pgeorgi on Sun 21st Apr 2013 12:04 UTC in reply to "RE: In the sidebar?"
pgeorgi Member since:
2010-02-18

Sometimes security by obscurity actually does work and unless they have made a deal with some OEM to sell haiku boxes I don't really see a point in this other than filling in a checkbox on a list, i really don't.

Right now it might be useless. But having the feature on by default makes sure that applications run in such an environment (and don't make weird assumptions). Which can come in handy should the feature ever become crucial.

Reply Score: 2

RE[2]: In the sidebar?
by Vanders on Sun 21st Apr 2013 13:39 UTC in reply to "RE: In the sidebar?"
Vanders Member since:
2005-07-06

Uhhh...how EXACTLY is this interesting? ASLR and DEP are fine and dandy for OSes that are being actively targeted but for haiku this is as useless as tits on a boar hog as we say down here.

ASLR and DEP can also help developers find bugs: things like dangling pointers to unreferenced memory quickly become apparent, for example.

Reply Score: 4

RE[3]: In the sidebar?
by bassbeast on Sun 21st Apr 2013 21:54 UTC in reply to "RE[2]: In the sidebar?"
bassbeast Member since:
2007-11-11

Well then TFA should say that, as not all of us are programmers and a little info can make all the difference.

Heck i learned more from you and that guy that posted in the thread about how shoddy some of the code is in Haiku (which he says is thanks to the GSoC bringing in junior programmers) than I did in the article itself.

Reply Score: 2

RE[4]: In the sidebar?
by anevilyak on Sun 21st Apr 2013 23:13 UTC in reply to "RE[3]: In the sidebar?"
anevilyak Member since:
2005-09-14


Heck i learned more from you and that guy that posted in the thread about how shoddy some of the code is in Haiku (which he says is thanks to the GSoC bringing in junior programmers) than I did in the article itself.


I'd suggest taking that other poster with a grain of salt. If he ever fixed anything about the pcnet driver, he never submitted a patch, and his name is otherwise not known as far as the community goes. Furthermore, there have been nearly identical comments about code quality posted by other people in past Haiku stories, which have been asked for details and/or examples of said shoddy code, at which the poster in question promptly disappeared without ever answering. I would regard that comment as hot air unless he intends to actually prove otherwise. There's also nothing wrong with the quality of code from the GSoC students, they do have mentors that review their code for good reason, and they're generally quite capable since the competition for a spot in GSoC is quite fierce, which tends to weed out the less able ones.

Edited 2013-04-21 23:15 UTC

Reply Score: 4

RE[3]: In the sidebar?
by moondevil on Mon 22nd Apr 2013 11:18 UTC in reply to "RE[2]: In the sidebar?"
moondevil Member since:
2005-07-08

ASLR and DEP can also help developers find bugs: things like dangling pointers to unreferenced memory quickly become apparent, for example.


A better solution for this is to have warnings as errors and make static analyzers part of the build process.

Reply Score: 3

Not all modern OS
by b00gie on Fri 19th Apr 2013 12:16 UTC
b00gie
Member since:
2006-06-09

Sadly the great majority of linux distros have half-baked ASLR support, most packages are not PIE-capable and the kernel implementation itself is not anything great either. Only gentoo seems to have an active hardened project this days.
Anyway, good to see Haiku expanding their security methods.

Reply Score: 8

RE: Not all modern OS
by Gullible Jones on Fri 19th Apr 2013 15:33 UTC in reply to "Not all modern OS"
Gullible Jones Member since:
2006-05-23

Modded up because it's true.

Windows 7 ASLR has issues too last I checked (though 8 is supposedly better). But yes, Linux exploit mitigation is AFAIK kind of weak, especially on x86-32.

Reply Score: 3

Security fail
by peteo on Fri 19th Apr 2013 13:24 UTC
peteo
Member since:
2011-10-05

I was (un)fortunate enough to get intimate knowledge about the Haiku source code after fixing the PCNet driver, and doing a few rounds of code review.

And I have to say that ASLR support at this point is pretty comical when the rest of the system basically ignores security.

A code review is long overdue.

GSoC is nice and all, but the students doesn't even avoid the most basic exploits (at a basic level, Haiku is littered with buffer overflow sensitive code, but that's the least of their problems from a security standpoint.)

As an avid BeOS fan, I sincerely hope they get their act together and start reviewing code properly before committing.

Reply Score: 1

RE: Security fail
by drcouzelis on Fri 19th Apr 2013 18:07 UTC in reply to "Security fail"
drcouzelis Member since:
2010-01-11

I'm a huge fan of Haiku, and I think your comment here is extremely important.

Do the Haiku developers know about your concerns? Considering other features, do you feel that fixing the security problems you mention a priority? If you haven't done so yet, would you be willing to list out what you feel needs to be done before you would consider Haiku to begin to be secure?

Do you think this is something that existed in BeOS, despite not being able to look at the source code?

Thank you! ;)

Reply Score: 4

RE[2]: Security fail
by peteo on Mon 22nd Apr 2013 18:26 UTC in reply to "RE: Security fail"
peteo Member since:
2011-10-05

I'm a huge fan of Haiku, and I think your comment here is extremely important.

[...]

Do you think this is something that existed in BeOS, despite not being able to look at the source code?

Thank you! ;)


I have obviously never seen the BeOS code, but from what I hear from the Be folks, they had serious security audits.

The reason why security became very important is of course the fact that they bet the company on BeOS in Internet connected appliances.

Edited 2013-04-22 18:27 UTC

Reply Score: 1

RE: Security fail
by v_bobok on Sat 20th Apr 2013 00:47 UTC in reply to "Security fail"
v_bobok Member since:
2008-08-01

Haiku is off GSoC this year, so no "ignorant students" this year, yaaay.

Patches are welcome, The Master of Security. xD

Reply Score: 1

RE: Security fail
by axeld on Mon 22nd Apr 2013 09:55 UTC in reply to "Security fail"
axeld Member since:
2005-07-07

I was (un)fortunate enough to get intimate knowledge about the Haiku source code after fixing the PCNet driver, and doing a few rounds of code review.


Are there any bug reports for your claims? Have you ever provided a patch?

Oh, and BTW Haiku is using FreeBSD's pcnet driver since six years.

Please troll somewhere else.

Reply Score: 4

RE[2]: Security fail
by peteo on Mon 22nd Apr 2013 18:23 UTC in reply to "RE: Security fail"
peteo Member since:
2011-10-05

"I was (un)fortunate enough to get intimate knowledge about the Haiku source code after fixing the PCNet driver, and doing a few rounds of code review.


Are there any bug reports for your claims? Have you ever provided a patch?
"

Yes, a lot of my patches were accepted, thank you very much.

Reply Score: 0

RE[3]: Security fail
by bebop on Mon 22nd Apr 2013 20:25 UTC in reply to "RE[2]: Security fail"
bebop Member since:
2009-05-12

You do realize that you are talking to two of the core dev's don't you? They have both been on the project from very early on, and I know for a fact that they both track the commit log and dev list closely.

I have also been watching the project for some time and have no idea who you are.

Reply Score: 4

v RE[4]: Security fail
by TempleOS on Mon 22nd Apr 2013 20:48 UTC in reply to "RE[3]: Security fail"
RE: Security fail
by bebop on Mon 22nd Apr 2013 20:19 UTC in reply to "Security fail"
bebop Member since:
2009-05-12

I call BS on this post. As someone who has contributed to Haiku, I can tell you that there are computer aided audits (coverity), and that the core developers are not only talented, but also very picky about the commits they let into the tree.

Also as axled pointed out, we have been using the FreeBSD net stack for sometime, so I do not buy your claim about being familiar with the Haiku source code. I have also not seen you in the dev list or on the commits.

If you see real problems, please feel free to file bug reports, preferably with diff's attached.

Reply Score: 4

Comment by lucas_maximus
by lucas_maximus on Fri 19th Apr 2013 20:09 UTC
lucas_maximus
Member since:
2009-08-18

Pretty damn cool. Very important feature of a modern OS.

Reply Score: 3

v Funny
by TempleOS on Sat 20th Apr 2013 10:32 UTC
RE: Funny
by WereCatf on Sat 20th Apr 2013 14:40 UTC in reply to "Funny"
WereCatf Member since:
2006-02-15

So, I have a single-address map for all tasks.


Problem one, right there: all applications get their own, private address mappings, it's not a global one.

When code is loaded, basically, it calls malloc() and puts the code there. Code gets put in random locations.


Problem two: it's not only the base location of the executable code itself that's randomized, it also applies to libraries, data, heap and such.

I have been doing this for years and Microsoft patented it and called it ASLR.


No, you haven't.

Reply Score: 6

RE[2]: Funny
by Alfman on Mon 22nd Apr 2013 09:50 UTC in reply to "RE: Funny"
Alfman Member since:
2011-01-28

WereCatf,


"Problem one, right there: all applications get their own, private address mappings, it's not a global one."

It doesn't need to be that way. I was talking to neolander a while back and a global mapping has some advantages when pages are shared because the pointers contained within those pages are valid in any process.

There are security implications depending on how it's used, but it's no worse than sharing pages at relocatable addresses since untrusted offsets would still need to be bounds checked
anyways. Trusted processes would have a much easier time sharing actual objects between them (and not just serializing objects to/from the shared page).

"Problem two: it's not only the base location of the executable code itself that's randomized, it also applies to libraries, data, heap and such."

It sounded to me sort of implied that his version of malloc did that. Maybe I read it too optimistically, but I don't think the post was worthy of the downvotes. (It didn't have the religious overtones like some of the other comments).

Edited 2013-04-22 09:52 UTC

Reply Score: 2

RE[3]: Funny
by WereCatf on Mon 22nd Apr 2013 10:35 UTC in reply to "RE[2]: Funny"
WereCatf Member since:
2006-02-15

It doesn't need to be that way. I was talking to neolander a while back and a global mapping has some advantages when pages are shared because the pointers contained within those pages are valid in any process.


If all processes shared a global mapping it would immediately counter the whole point of ASLR: if your process couldn't access or allocate a certain memory location you'd immediately know that it's in use. Virtual address mappings are a security feature designed exactly for this as the application can request ANY address whatsoever and it wouldn't know if it is physically at that location or not or if that physical location is used by something else and the application was instead given a virtual mapping.

There are security implications depending on how it's used, but it's no worse than sharing pages at relocatable addresses since untrusted offsets would still need to be bounds checked
anyways. Trusted processes would have a much easier time sharing actual objects between them (and not just serializing objects to/from the shared page).


You do realize that you can still share the same, physical location between multiple applications even with private, virtual address mappings? Most OSes do provide facilities for this -- the OS only needs to map the same, physical address to some random private address on the processes' sides and then let the processes know which address to use.

It sounded to me sort of implied that his version of malloc did that. Maybe I read it too optimistically, but I don't think the post was worthy of the downvotes.


I wasn't the one downvoting him, so that's irrelevant wrt. my comment. But I didn't interpret his comment as you did, I interpreted it that he simply randomizes the base location he mallocs for the process and places it all there.

Reply Score: 2

RE[4]: Funny
by Alfman on Mon 22nd Apr 2013 21:33 UTC in reply to "RE[3]: Funny"
Alfman Member since:
2011-01-28

WereCatf,

"Virtual address mappings are a security feature designed exactly for this as the application can request ANY address whatsoever and it wouldn't know if it is physically at that location or not or if that physical location is used by something else and the application was instead given a virtual mapping."

Virtual mappings don't need to match the physical ones in order to have a global mapping. In fact it helps reduce multi-page fragmentation when they don't.

Just because all processes share the global page map doesn't imply all processes know which pages are used by which processes, nor even which pages are allocated at all unless you have functions that leak this sort of information.


"You do realize that you can still share the same, physical location between multiple applications even with private, virtual address mappings? Most OSes do provide facilities for this -- the OS only needs to map the same, physical address to some random private address on the processes' sides and then let the processes know which address to use."

Data pointers use logical addresses, not physical ones. Creating two different logical mappings to the same physical address isn't the same as two processes sharing logical mappings. It's an interesting (unconventional) use case, but it could facilitate the sharing of objects between processes of similar permissions.

While linux's version of mmap allows virtual address hints, it's hit or miss whether the processes that want to share the region will be able to map at the same location because they use a local page map.

I wouldn't actually use the technique myself, but I don't see any reason it'd be incompatible with ASLR.

Reply Score: 2

v Comment by TempleOS
by TempleOS on Sat 20th Apr 2013 16:33 UTC
Comment by TempleOS
by TempleOS on Sat 20th Apr 2013 16:56 UTC
TempleOS
Member since:
2013-04-03

I just found this:

http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%2...

That's retarded! It reminds me of when I was doing PIC $1.60 toner cartridge chips. My coworker made a reprogrammer with a rabbit processor and tried to do C or BASIC, I forgot. He does not know asm.

I face-palm when someone uses C or BASIC on an 8-bit because they don't know asm -- too lazy. That's just dreadful and nasty.

No, running Linux is stupidly absurd!

Edited 2013-04-20 16:58 UTC

Reply Score: 0

v RE: Comment by TempleOS
by TempleOS on Sat 20th Apr 2013 20:19 UTC in reply to "Comment by TempleOS"
RE[2]: Comment by TempleOS
by bassbeast on Sun 21st Apr 2013 12:10 UTC in reply to "RE: Comment by TempleOS"
bassbeast Member since:
2007-11-11

Dude I know 4/20 was yesterday but you should really think about not blowing through a couple bongs and then posting, just saying.

Reply Score: 6

v Silence of the Lambs
by TempleOS on Mon 22nd Apr 2013 02:21 UTC
v RE: Silence of the Lambs
by TempleOS on Mon 22nd Apr 2013 02:44 UTC in reply to "Silence of the Lambs"
v Mine
by TempleOS on Mon 22nd Apr 2013 21:44 UTC