They said "unlikely" not "impossible". I guess it is unlikely because no one is willing to put in the massive resources needed to port Rust to an archaic platform.
Please note that Haiku is among the supported OSs of the LLVM compiler framework while OS/2 isn't. So unless you want to re-create a Rust compiler from scratch you would first need to port LLVM to OS/2.
Yeah, the backend not being available is certainly a showstopper, thanks. GCC being ported to every silicon-based system under the sun does blind one to the fact that that isn't necessarily true for its rivals.
Writing an OS/2 backend for a language that uses LLVM isn't impossible, but it's hard, hard work. Writing or porting a linker, implementing the low-level parts of the Rust runtime.
Fixing bugs likely requires being fluent in all of Rust, C++, LLVM IR and OS/2's variant of x86 assembly, and tracing causes from the Rust frontend through a dozen layers and subsystems until their effect show up in x86. You may think I'm exaggerating.
I don't think that you're exaggerating, but writing a browser is also a lot of very hard work. And writing a browser is only writing a single application; implementing a LLVM backend, however, is supporting thousands of potential applications. Wouldn't it make much sense to raise funds towards this goal?
Also, browser is one of the main attack surfaces in modern web, and writing your own browser instead of sticking with a huge project that benifits from researchers all around the globe just doesn't sound right. Especially since OS/2 has a lot of legacy use in corporations that can be targetted for an attack.
OK, I understand why someone might need to maintain and deploy an OS/2 app deep within some enterprise backend, but why on earth is anyone trying to browse the web with it?
Put differently, why would anyone in their right mind use OS/2 to browse the web, given that it misses more than two decades in development of security techniques. As far as I understand Mensys and now Arca Noae never had the source code to the OS/2 kernel or foundational libraries. Given that this code was written in the late eighties-half nineties in a largely pre-internet world:
- It's likely that many of the libraries are full of buffer overflows, double frees, dangling pointers, etc.
- OS/2 is not a multi-user system, there is no boundary between a user and a root-like account.
- OS/2 does not have modern mitigation techniques like (K)ASLR, probably no PIE/PIC, stack canaries, etc.
- OS/2 (AFAIR) does not offer sandboxing facilities, such as seccomp, capsicum, or pledge.
- OS/2 has no protection against recent CPU vulnerabilities.
So, if you are using OS/2 to browse the web, you are purely relying on security through obscurity.
- change default port for sshd will take away 99.9% off all random attacks.
- many copy protections may count as this. Some of them uncrypt themself before running so that it is harder to disassemble the bin file on disc. Also some more creative protections have been around, https://www.makeuseof.com/tag/5-strange-video-game-copy-prot...
> change default port for sshd will take away 99.9% off all random attacks.
Not running SSH takes away 100% of all SSH attacks. Only allowing certain IPs to connect also takes away more than just changing the port number. Its a matter of convenience and effort though.
Lots of systems are based on "defence in depth", i.e. multiple layers of security.
This approach acknowledges that any single layer of security will have holes somewhere just waiting to be found no matter how theoretically secure you think it is.
The implementation matters, not the theory and quite often this is where the holes exist.
"Obscurity" is just one of those layers.
Given no security, e.g. wide open front door, adding a door will reduce the number of successful attackers. Having a lock & key is a level up, hiding the key would reduce the chances of a successful burglary even more. Armed guards on the door would again reduce the chances of you getting burgled. Adding barbed-wire around your house improves the situation again... and it goes on.
None of those levels of defence are impenetrable, but they all help.
Well, we often differentiate between "security by obscurity" and "obfuscation" since former became a common insult/no-no. The former is when enemies not knowing how something works is the security strategy. Lots of those systems fall easily. The latter is when it's an extra defense on top of otherwise good, security practices or at least a baseline not much different than what's common.
I've found obfuscation an essential tool to delaying or defeating high-strength attackers. I tried to apply it to every level of the computing stack in my research. Here's a write-up with examples you could use:
I appreciate most of your posts regarding high-assurance but don't get used to your ideas on security by obscurity. Of course you shouldn't make it easy for attackers to get much information of your systems but you probably should do it for security evaluators.
If security by obscurity doesn't take much effort and doesn't interfere with standard security principles (actually it does already when we think about open design/Kerckhoffs's principle
, but what I mean is something like complexity increase) it may not harm your security. But if you spent to much effort, that effort could have probably been better used to increase the assurance of the system to be protected.
I mean it does not sound very trivial and very beneficial to hide your CPU architecture from attackers. Maybe the effort is just is better spent in the assurance of the exposed network service or the compartmentalization of it.
"that effort could have probably been better used to increase the assurance of the system to be protected."
Think about that kind of hard. The average person or developer would have to know how to block about everything a hacker can think of on their known configuration. Whereas, a hacker or group knowing nothing of their configuration aiming for highest number of compromises will focus on something widely known or used. Even the recent router hacks were devices that sold by the truckload. Even for a targeted scenario, they still gotta get information most of your employees won't even have if it's backend stuff. Much of what runs at my company is terminal, client server, and web apps on non-descript boxes all through VPN's and such. The attackers have to breach the strongest components or convince someone in IT to give them necessary information. How easy that con is varies company to company but there's methods for reducing risk of it, too.
Using a different PDF reader, web server, embedded ISA, and so on takes barely any effort or brains. If its own defaults are decent, the switch immediately gives benefit of less, successful attacks with less downtime or restores needed. Even better if behind a guard that hides what things are running by faking an Intel Windows or Linux box. The few that implemented this strategy told me they went years without problems. If any of it gets popular, that benefit might go away. Worse is Better works in our favor for obfuscation, though. The crowds chase the worse things. The attackers stay right behind them. ;)
EDIT:
"If security by obscurity doesn't take much effort and doesn't interfere with standard security principles (actually it does already when we think about open design/Kerckhoffs's principle , but what I mean is something like complexity increase) it may not harm your security."
Yeah, that's basically how I look at it. It shouldn't invalidate the existing mechanisms. It shouldn't take too much effort. Maybe a bit upfront one time for setup with maintenance being rather low. What one is looking for with obfuscations is that they knock out the average attacker's foothold into boxes or networks without using much time for defender. For high-strength attackers, they should be combined with detection mechanisms so they might expose themselves blindly trying attacks.
They aren't using OS/2 to browse the WWW. They are using Mozilla Firefox to browse the WWW. In case you missed it, the headlined article even tells you that this is version 52 of Firefox, from March of last year.
The same goes for many of these libraries that you vaguely allude to. They aren't part of the operating system. Almost all such major programs tend to have layers of either Unix-alike or Windows-alike libraries over the top of the operating system API. They are third-party add-ons, presumably built from equally recent versions.
And that goes a long way down. This isn't Unix. There is no single, distinguished, "the" C library. Every compiler has its own C libraries.
They aren't using OS/2 to browse the WWW. They are using Mozilla Firefox to browse the WWW.
In the end there will still be calls into the Presentation Manager to render pages on screen. Also, TCP/IP are handled through system libraries (tcp32.dll, so32dll.dll). So, there is a large surface area where Firefox will use system libraries.
Besides that, the web browser can have vulnerabilities and runs untrusted code. It's pretty insane to use a browser in 2018 that doesn't execute Javascript in sandboxed processes.
Mozilla Firefox not sandboxing Javascript is not an OS/2 problem. It is a Mozilla Firefox problem.
The problems with WWW browsers are not solved on other operating systems, are a lot more to do with a user being vulnerable to processes running as xyrself which multi-user semantics will not address on any operating system until the world starts taking advantage of GNU Hurd or nonce SIDs, and in large part lie within the application.
They lie in cryptography implementations, in the architecture of downloading programs across the WWW from arbitrary third parties and running them, in the access from one WWW site to another, in the architecture of "Web APIs" and non-document WWW sites, in document model implementations, and so forth. Presentation Manager and low-level sockets form almost none of this. You are positing that the major locus for flaws is libraries that literally provide the low-level read()/connect()/bind()/&c. library functions. Whereas the add-on libraries that the people porting these applications have to also build, from SSL libraries through HTML parsers to PNG and MPEG processors, form a lot of it; but are not part of OS/2 nor set in stone.
You cannot have your cake and eat it. Either OS/2 comes with this stuff and it is a problem that the stuff is old with known vulnerabilities, or the problem is (as indeed explained in the headlined article) that OS/2 does not come with this stuff and a large amount of effort is needed in porting all of these modern libraries, runtimes, and even whole language development toolsets to OS/2. The reality is the latter. They are, after all, asking for money for doing one part of exactly that.
But that reality means that vague handwaving about "written in a pre-Internet world" (which it of course was not, the Internet pre-dating any version of OS/2 by about a decade) is ill-thought. The irony is that the vast bulk of the so-called "surface area" in a WWW browser is in all of these application layers and libraries that are modern.
Or, put more glibly: I don't expect any Javascript security holes in IBM WebExplorer ever.
What does “pre-internet” have to do with “buffer overflows, double frees, dangling pointers”?
I have no evidence, but I wouldn’t be surprised if code from them had less of these since there were far fewer code jockies that just hacked together code they don’t quite understand from google search results. I think most programmers then were much more classically trained.
No, old programmers would do much worse. And the threat model for those systems didn't take in the web as an attack surface. The bugs described would only help with local privilege escalation before. Now they can be used to get access to the networked application.
E.g. the browser uses a vulnerable library call with input from a web page, and that library call alters the return stack according to the input. The browser is now compromised.
I don't think they mean "old" programmers exactly... more like "programmers back in the day". We just didn't have the quality of tools back then. Also, our machines were orders of magnitude less powerful, which meant we generally had to work with a lot less in the way of things like library support, frameworks, etc. I used to have an OS/2 box as my build machine. I think that box had 32k of RAM, and 4.7Mhz processor.
Yes, not nearly the quality of tools. When I was programming back then I programmed much closer to the cpu (less abstraction through libraries and less automated tools). This made me look much closer at the issues listed above. I also ready full books on the programming language and command sets. Unlike now, if I use a new library/language, I just scan the online docs to get the gist of what I need to do.
Yeah, I did all those things as well. They were essential. And yet I would say that at least 50% of the bugs we ran into were either buffer overflows, stack overflows, using freed pointers, not freeing pointers, or incorrect pointer indirection. At least we didn't have to worry about race conditions.
Heh... see, it was the distant past, fading from my memory. You're absolutely right. The machine in question was an early pentium box as I recall, and the fastest machine I'd ever used at the time.
Yes, precisely. I count myself as one of them. SO and other things online provide a minimum quality level for many solutions, and we didn't have that a few years ago. So you did what you could with the meager time and resources available.
I was there. We had plenty of those kind of problems in those days. I also had the classical training of which you speak, but the industry was far ahead of academia in terms of actually dealing with that kind of thing. The reason pre-internet is relevant is that the penalty for a buffer overflow in 1995 might be a crashed app, or maybe a corrupted file. It was only later that the penalty became "getting pwned by some sophisticated bit of malware and needing to send monero to someone to get your compter back".
Buffer overflows to gain remote access to a computer were fairly well known in 1995. "Smashing The Stack for Fun and Profit" (http://phrack.org/issues/49/14.html) came out the following year.
Most people weren't really writing network facing code though, so most buffer overflows were as you described. They just resulted in seemingly random crashes.
>why would anyone in their right mind use OS/2 to browse the web, given that it misses more than two decades in development
From the Arca Noae web site: "Firefox 38.8ESR is included by default, and 45.5ESR will be available soon as an update. Full HTML5 support is included. Visit YouTube and play what you like."
And that was more than a year ago. I expect it's been updated since then.
I love NetSurf and I love that it even exists. It's fun browsing pages in a reasonable fashion on my '060 Amiga 4000T.
However, NetSurf's DOM and JavaScript support is embryonic by comparison, and sites other than static pages generally don't work. It's slowly improving but it's nowhere near Gecko, WebKit or Blink.
eComStation and ArcaOS are commercial software, shouldn't their developers be the ones paying for the effort to keep their clients' software cheaper to maintain on their legacy platforms than rewriting it to something better-supported?
There are actually developers that had given a lot of open source software to the platform (OS/2) without expecting nothing in return. But cloning OS/2 to turn it open source is a very long task and we don't have enough hands on the community.
But eComStation and ArcaOS uses IBM's binaries (OS/2 binaries), so to be a legal product an agreement and $$$ has to be given to IBM to be able to distribute a resell the binaries. So, it can not be a free product until some developers clone an open source replacement for the OS/2's binaries.
If you have doubts you can visit OS2World.com and ask on the forum.
Author (of the post you reference) here. On https://forge.rust-lang.org/platform-support.html every single triple with SPARC in it lacks cargo, and only a single Tier-3 port has rustc (NetBSD). Solaris and Linux just have std. That's not a port, that's barely a beachhead.
If you know this has changed, then the maintainers need to update that.
That's SPARC people and TenFourFox folks. The former just used regular Firefox with Solaris or Linux, the latter a backported Firefox for version of OS X that Apple abandoned (both PPC and Intel, IIRC).
TenFourFox isn't SPARC but PowerPC. Rust runs on PowerPC but not on OS X on PowerPC. OS X earlier than 10.7 lacks at least some thread-local facilities that Rust expects.
The other problem is no LLVM that runs reliably on 10.4/10.5. fang did some early work on this but nothing current is known to run. I just don't have the inclination or desire to port that and Rust and work around the thread-local storage problems (which probably won't work around all that well).
For those wondering what Warpstock 2018 Toronto had to do with it, that is apparently a mis-print in an article written in 2017. (-: Here is Warpstock 2017:
68 comments
[ 3.3 ms ] story [ 148 ms ] threadHere's a link about porting the Rust compiler to the Haiku OS: http://rust-on-haiku.com/wiki/PortingRust
Please note that Haiku is among the supported OSs of the LLVM compiler framework while OS/2 isn't. So unless you want to re-create a Rust compiler from scratch you would first need to port LLVM to OS/2.
Fixing bugs likely requires being fluent in all of Rust, C++, LLVM IR and OS/2's variant of x86 assembly, and tracing causes from the Rust frontend through a dozen layers and subsystems until their effect show up in x86. You may think I'm exaggerating.
Also, browser is one of the main attack surfaces in modern web, and writing your own browser instead of sticking with a huge project that benifits from researchers all around the globe just doesn't sound right. Especially since OS/2 has a lot of legacy use in corporations that can be targetted for an attack.
> ...OS/2
...probably not. Wouldn't mind if that weren't the case, but that's fundamentally a legal problem IMO (impossible to open source etc).
* http://ecomstation.com/
* https://www.arcanoae.com/arcaos-5-0-now-available/ (https://news.ycombinator.com/item?id=14359630)
- It's likely that many of the libraries are full of buffer overflows, double frees, dangling pointers, etc.
- OS/2 is not a multi-user system, there is no boundary between a user and a root-like account.
- OS/2 does not have modern mitigation techniques like (K)ASLR, probably no PIE/PIC, stack canaries, etc.
- OS/2 (AFAIR) does not offer sandboxing facilities, such as seccomp, capsicum, or pledge.
- OS/2 has no protection against recent CPU vulnerabilities.
So, if you are using OS/2 to browse the web, you are purely relying on security through obscurity.
- change default port for sshd will take away 99.9% off all random attacks.
- many copy protections may count as this. Some of them uncrypt themself before running so that it is harder to disassemble the bin file on disc. Also some more creative protections have been around, https://www.makeuseof.com/tag/5-strange-video-game-copy-prot...
Not running SSH takes away 100% of all SSH attacks. Only allowing certain IPs to connect also takes away more than just changing the port number. Its a matter of convenience and effort though.
"Obscurity" is just one of those layers.
Given no security, e.g. wide open front door, adding a door will reduce the number of successful attackers. Having a lock & key is a level up, hiding the key would reduce the chances of a successful burglary even more. Armed guards on the door would again reduce the chances of you getting burgled. Adding barbed-wire around your house improves the situation again... and it goes on.
None of those levels of defence are impenetrable, but they all help.
"Security by obscurity alone is discouraged and not recommended by standards bodies" (https://en.wikipedia.org/wiki/Security_through_obscurity)
I've found obfuscation an essential tool to delaying or defeating high-strength attackers. I tried to apply it to every level of the computing stack in my research. Here's a write-up with examples you could use:
https://news.ycombinator.com/item?id=11856351
If security by obscurity doesn't take much effort and doesn't interfere with standard security principles (actually it does already when we think about open design/Kerckhoffs's principle , but what I mean is something like complexity increase) it may not harm your security. But if you spent to much effort, that effort could have probably been better used to increase the assurance of the system to be protected.
I mean it does not sound very trivial and very beneficial to hide your CPU architecture from attackers. Maybe the effort is just is better spent in the assurance of the exposed network service or the compartmentalization of it.
Think about that kind of hard. The average person or developer would have to know how to block about everything a hacker can think of on their known configuration. Whereas, a hacker or group knowing nothing of their configuration aiming for highest number of compromises will focus on something widely known or used. Even the recent router hacks were devices that sold by the truckload. Even for a targeted scenario, they still gotta get information most of your employees won't even have if it's backend stuff. Much of what runs at my company is terminal, client server, and web apps on non-descript boxes all through VPN's and such. The attackers have to breach the strongest components or convince someone in IT to give them necessary information. How easy that con is varies company to company but there's methods for reducing risk of it, too.
Using a different PDF reader, web server, embedded ISA, and so on takes barely any effort or brains. If its own defaults are decent, the switch immediately gives benefit of less, successful attacks with less downtime or restores needed. Even better if behind a guard that hides what things are running by faking an Intel Windows or Linux box. The few that implemented this strategy told me they went years without problems. If any of it gets popular, that benefit might go away. Worse is Better works in our favor for obfuscation, though. The crowds chase the worse things. The attackers stay right behind them. ;)
EDIT:
"If security by obscurity doesn't take much effort and doesn't interfere with standard security principles (actually it does already when we think about open design/Kerckhoffs's principle , but what I mean is something like complexity increase) it may not harm your security."
Yeah, that's basically how I look at it. It shouldn't invalidate the existing mechanisms. It shouldn't take too much effort. Maybe a bit upfront one time for setup with maintenance being rather low. What one is looking for with obfuscations is that they knock out the average attacker's foothold into boxes or networks without using much time for defender. For high-strength attackers, they should be combined with detection mechanisms so they might expose themselves blindly trying attacks.
The same goes for many of these libraries that you vaguely allude to. They aren't part of the operating system. Almost all such major programs tend to have layers of either Unix-alike or Windows-alike libraries over the top of the operating system API. They are third-party add-ons, presumably built from equally recent versions.
And that goes a long way down. This isn't Unix. There is no single, distinguished, "the" C library. Every compiler has its own C libraries.
In the end there will still be calls into the Presentation Manager to render pages on screen. Also, TCP/IP are handled through system libraries (tcp32.dll, so32dll.dll). So, there is a large surface area where Firefox will use system libraries.
Besides that, the web browser can have vulnerabilities and runs untrusted code. It's pretty insane to use a browser in 2018 that doesn't execute Javascript in sandboxed processes.
The problems with WWW browsers are not solved on other operating systems, are a lot more to do with a user being vulnerable to processes running as xyrself which multi-user semantics will not address on any operating system until the world starts taking advantage of GNU Hurd or nonce SIDs, and in large part lie within the application.
* http://explainxkcd.com/wiki/index.php/1200:_Authorization
They lie in cryptography implementations, in the architecture of downloading programs across the WWW from arbitrary third parties and running them, in the access from one WWW site to another, in the architecture of "Web APIs" and non-document WWW sites, in document model implementations, and so forth. Presentation Manager and low-level sockets form almost none of this. You are positing that the major locus for flaws is libraries that literally provide the low-level read()/connect()/bind()/&c. library functions. Whereas the add-on libraries that the people porting these applications have to also build, from SSL libraries through HTML parsers to PNG and MPEG processors, form a lot of it; but are not part of OS/2 nor set in stone.
You cannot have your cake and eat it. Either OS/2 comes with this stuff and it is a problem that the stuff is old with known vulnerabilities, or the problem is (as indeed explained in the headlined article) that OS/2 does not come with this stuff and a large amount of effort is needed in porting all of these modern libraries, runtimes, and even whole language development toolsets to OS/2. The reality is the latter. They are, after all, asking for money for doing one part of exactly that.
But that reality means that vague handwaving about "written in a pre-Internet world" (which it of course was not, the Internet pre-dating any version of OS/2 by about a decade) is ill-thought. The irony is that the vast bulk of the so-called "surface area" in a WWW browser is in all of these application layers and libraries that are modern.
Or, put more glibly: I don't expect any Javascript security holes in IBM WebExplorer ever.
But I think the point of the article is to gather funding to build a new browser for the future (1.5-2 years away) when their Firefox support ends?
I have no evidence, but I wouldn’t be surprised if code from them had less of these since there were far fewer code jockies that just hacked together code they don’t quite understand from google search results. I think most programmers then were much more classically trained.
E.g. the browser uses a vulnerable library call with input from a web page, and that library call alters the return stack according to the input. The browser is now compromised.
So I guess I had the opposite experience.
That machine was probably worth about 3-4 grand at the time (1992)
You would need at least a 386 to support 32 megs of RAM. Those were at least 16 mhz.
Most people weren't really writing network facing code though, so most buffer overflows were as you described. They just resulted in seemingly random crashes.
From the Arca Noae web site: "Firefox 38.8ESR is included by default, and 45.5ESR will be available soon as an update. Full HTML5 support is included. Visit YouTube and play what you like."
And that was more than a year ago. I expect it's been updated since then.
They've raised $12,650 and think it will take around 18 months.
However, NetSurf's DOM and JavaScript support is embryonic by comparison, and sites other than static pages generally don't work. It's slowly improving but it's nowhere near Gecko, WebKit or Blink.
There are actually developers that had given a lot of open source software to the platform (OS/2) without expecting nothing in return. But cloning OS/2 to turn it open source is a very long task and we don't have enough hands on the community.
But eComStation and ArcaOS uses IBM's binaries (OS/2 binaries), so to be a legal product an agreement and $$$ has to be given to IBM to be able to distribute a resell the binaries. So, it can not be a free product until some developers clone an open source replacement for the OS/2's binaries.
If you have doubts you can visit OS2World.com and ask on the forum.
* http://articles.os2voice.org/category/voice/12-update-on-the...
And further follow-ons as already mentioned in this discussion.
* https://news.ycombinator.com/item?id=17461751
* http://tenfourfox.blogspot.com/2018/07/another-one-bites-rus...
If you know this has changed, then the maintainers need to update that.
I will send updates to the page. Thanks!
* http://warpstock.org/staticpages/index.php?page=ws2017_sessi...
Maybe Gates could cough up something, just for the irony.