dyld is still extremely vulnerable

Stephen/whom it may concern,

resending this message three weeks after initially responding; I am not sure it was received and it contained serious concerns and expressed more than a hope for immediate resolution. the change in exact subject may have in my estimation affected a forward, as i've received email from several individuals via this one address, as this is an urgent matter, i do not intend to be ignored, and am taking this reasonable step to ensure my best effort is given to communicating effectively these serious security concerns, which absent addressing, are an absolute blocker on my ability to guarantee the security of this application on this platform. there is much substance here beyond what you have stated can't be addressed and to dismiss the entirety of these concerns is bot h disturbing and at this point resulting in an unreasonable restraint on our commercial activities which i would like to resolve with reasonable measures. as for the kext request, it is certainly unreasonable that google via osxfuse has been able to sign a kext that is identical, or at the most very slightly modified  (removing dlopen), to the fork screwjack audited and wishes to sign to guarantee integrity of the whole of this application, nemesis full disk encryption. any other requests not withstanding, derivatives, etc, that particular request is the specific request primarily at issue, and while resubmitting this email which i do truthfully suspect was received without incident the first time - i would like to add,and make clear, this inconvenience is well past what it has been trivialized to in the second response  screwjack received, and while not necessary via obligation, it seems patently ridiculous to me that one entity should be authorized to sign an arbitrary fork of a piece of software - osxfuse itself is in fact a fork of other code, from linux, and bsd, in fact, as exercise, i've compiled the original linux library code on os x with some porting .....and we should be arbitrarily restrained from commerce in our just as legally valid fork of the same code.

i am at the point where i see no further point in investing time on a platform that has been so roundly panned for security lately and in addition to dismissing and trivializing valid concerns regarding security...am then effectively denied the ability to fix what should be in our power to for our users. shortly after making these last disclosures an attempt to ddos one of our distribution points failed,but notably, it was an unadvertised unpromoted point, which in the last couple of months, was only mentioned once here and once to a confidential government contact. this  particular application is popular across several platforms and while it is the least next generation of our offerings it has a role to play as one of the most visible. should this again be ignored, screwjack will find it impossible to guarantee the security of this application on this platform.

i believe you seriously underestimate the value and import we are assigning to the issue of both security, specifically as covered repeatedly here, and the grave seriousness of the flat impossibility of accepting someone else's signed fork of the FUSE kext, particularly that of a PRISM partner such as Google, as a viable option for encryption not found in a package of crackerjacks on a ring.

this is far beyond reasonable and far too long a delay for me to exhibit any further understanding of anything other than "yes" or "no" for an answer. and "no" would seem extremely specious and indefensible, i understand, but this is singularly the purpose for which Screwjack has  enrolled in this program, and it was with assurances from Apple that this  very precise need would not be a problem to address.

respectfully and with demand for all available escalation,

jonathan derose

screwjack, llc

regarding: additional correspondence regarding our restraint from trafficking in our own  fork of the linux FUSE code derived kext that a google related initiative has been able to sign for years prior to our initial request to sign a fork of said code, a few of months ago. the tone of this communication is nothing less than a reflection and moderation of the tepid response we have received in kind. good day.

forwarded message:
---------- Original Message ----------
From: jonathan derose <poet@screwjackllc.com>
To: devprograms@apple.com, Patrick@sadeklaw.com
Date: December 4, 2017 at 1:54 AM
Subject: Re: My issue is not listed/kext signing request

Stephen,

That's more tolerable given the human nature and existence of this response; pardon but, I am somewhat frustrated and rather restrained in my ability to release something I can ethically market as secure open source full disk cryptography presently as a result, for this platform alone. In addition that was not the sole thing I wished to discuss, I generally don't prefer digital modes of communication for certain things, where there are some I demand it of associates, in the case of something of such critical bearing I find it much easier to know who I am dealing with and allow them the opportunity to address concerns that are relevant yet wider than the bare bones of the technical issue itself...character and trustworthiness go a long way to me, and having worked much in this area, they are critical to building trust, and with out that, you can't build a trusted system at all. I've cc'd counsel as procedure to have everything recorded, that's not a concern, but prudence requires it - honestly that was another issue with the process. If it had not been such a critical issue I would have not normally used a web form to get through, because as practice, all correspondence on this issue is our policy to carbon copy our counsel for the record, and it's not feasible to keep a proper record with web forms without some effort. Digital forensics being another field of interest, record keeping, operational security, and procedure are all important to me. So in that sense I do understand the need to vet software. Unfortunately here, there is an extension in the chain, that completely fails our internal vetting, and in point of fact, addressing that issue by developing a solution is fairly the sole reason Screwjack pushed on to enroll as Apple developer; we've not got a business interest or even a philanthropic one, outside of security hardening and digital forensics related work. This is our entire purpose, and I appreciate knowing this is not on the back burner; while I understand the need of Apple, I need to know when to mark an issue as notfix/wontfix and move forward as at this point I am leaving an application that builds on four platforms in an insecure state on this one, which is a problem, as this is the only platform where we target binary builds...there's a windows rework based on MinGW showing some promise, the original code used Visual Studio, but, this is a complete rewrite as in the initial fork of our application, that code was removed for, of course, reasons of security; it was too inconsistent in memory handling and required too much individual attention to provide proper attention, and the intent has always been addressing security first, so the entire platform was dropped and only recently came back, to active development, frankly in part as a result of this. The target isn't so critical as the dissemination potential.

I'd point out once more though, that it's really actually untenable to release further on the platform without being able to guarantee a secure path to IOKit from our software, and the fact is, the initial request precisely concerns the OSXFuse kext that has already been vetted and approved once. The problem is, that build, is not trustworthy or acceptable in this use case; for many reasons.

The rest of the last communication dealt with specific concerns that were partially related to the request and partially an effort to show some good faith by demonstrating a POC and giving engineering some possibly useful work product of mine resulting from toolchain regressions working with various generations of linkers, I do a lot of work presently, on toolchains, and I'm also vicious with micro optimizing as it tends to expose interesting and sometimes useful behaviors, and I've found a way to generate static executables over 80% smaller than the current strip distributed with Xcode llvm allows, while retaining binary compatibility with the current dynamic linker. I was until this succeeded unaware of the DYLD_PRINT_TO_FILE issue, and privilege escalation around it, but I also have a concern that may still be a problem, which makes me yet even more uncomfortable using google sponsored work to link our code to IOKit.

The work I have in that case was and is solely to reduce binary size by cutting down relocations and performing a more effective binary strip; the concern, stems from the fact that the current strip addresses that prior issue it appears solely by not stripping relocations.

There's also some concern to me that the image activators are included in the dyld package while on BSD they appear in the kernel; this is why I initially mentioned /stand and /rescue, it's far too great a single point of failure for my needs and this is what prompted my work in this direction on producing static linked rescue tools which so far has been entirely successful. By using gnu strip on my binaries, then running them through objcopy, to recreate the proper header, and then for now using a hex editor (i actually used an old apple utility bundled with the NeXT compiler code, hexdump, to spot the diff), to remove some junk gnu strip leaves behind, I'm able to make my static binaries far more lithe...I don't need a 500mb copy of busybox either, but I go from 2mb to 300k. Now I know you all use dynamic linkage most of the time but as a system programmer primarily I'm sure you also use enough static linkage to appreciate binutils that are more well adjusted, and I also wanted to mention that should I revise a strip to automate my more efficient relocation stripping while still preserving the correct header information, you'd be welcome to do whatever you wish with the patches I produce.

I'm disclosing this in good faith as it's what I've found in the course of philanthropic work done non profit and in the interest of advancing security, hoping that you can either rest knowing I'm incorrect about dyld, or, fix a problem that could hit several ways and extremely badly should a malicious actor have been working on something as mundane as linkage and accidentally found the leeway I have here...while I haven't called out  specific concerns I've granted enough here that I am sure a competent engineer would be able to, and the exploitation was not my concern here; I am trying to write cryptography immune to side channel attacks, not write side channel attacks. In this case, I don't particularly care about the problem or it's extent, but I know how to make sure whether or not it is a major issue, my end users are protected, and that is by distributing verified builds of code without  what I can not verify. This is why I do thank Apple for releasing open source, and I do hope this is internally useful. In that case, I of course have zero expectation of a christmas card due to the nature, but in the event it does, you're welcome, that's why I'm here.

I'd be willing to bet, a not insignificant amount, that that linker issue is not fully resolved as a result of this, and with consideration for that, I do ask for the ability to secure my software and I would greatly appreciate a measure of priority commensurate with the validity of my concerns. I have some very specific technical issues with using the kext in question stemming from suspect or negligent practice on behalf of the OSXFuse project in the build of the library that accompanies it I can address by building it without support for it's own dynamic loading, and have, but the fact that OSXFuse uses google staff on or off payroll is a major obstacle to trusting the remainder of their code and as is, that invalidates my entire project on OS X and, unfortunately, unless addressed, if it were to turn out to be an issue later, would have made it a failure on my part personally to secure my users data and completely destroy trust built up over decades in coding on multiple platforms with a mind for security; I can't deliver to one expectation everywhere else and have a different standard for the same codebase here, so, time is truly not on my side. I need to resolve this, and presently, or move to a platform that I can guarantee honestly. There is a lot here that deeply troubles me security wise. And again - the code i need to build, is open source and has already been approved for others to build.

Thanks much,

I look forward to resolving this amicably and rapidly,

Jonathan
> On December 2, 2017 at 1:00 PM devprograms@apple.com wrote:
>
>
> Hello Jonathan,
>
> Thank you for following up with us and for providing some additional information about your KEXT request status. My name is Stephen, and I am a senior Advisor with Apple Developer Program Support. I will be taking over your case from Lauren.
>
> I can understand your frustration with this process. I can also assure you that we are continuing to review the status, and someone will follow up with you as soon as there is an update. Please understand that we are unable to provide an estimated time for resolution.
>
> In your follow up you requested to speak with someone regarding this request, however an Advisor with this group will be unable to comment on the status of the KEXT request. I appreciate your continued patience with this process. You will be contacted as soon as an update is available.
>
> Case number: 100366081805
>
> Best regards,
>
> Stephen
> Apple Inc.
>
> On Dec 1, 2017, at 23:43 jonathan derose <poet@screwjackllc.com> wrote:
>>
>>
>> Hi Lauren,
>>
>> Thanks for the response the most frustrating part to me has been the lack of human contact, and the webforms. Honestly I don't feel adequately able to represent Screwjack's interests unless I'm speaking to someone directly, and I appreciate the opportunity to respond and would be happy to call in and discuss things if it accelerates this process. I apologize in advance for the length of this response but, I'm passionate about the work and I also feel like I should qualify my response some, considering the volume of code I've got in the wild, the fact I don't label or advertise 99% of through normal channels, and the fact that it's under a license of entirely free, i don't care what you do with it.
>>
>> I have actually three requests in, with some time between each, and the most recent is 677530318. I realize I'm longwinded,but I'm pretty sure Richard Stallman is far worse...anyhow that's the number so I doubt the rest is of critical import but I'd like to be thorough and answer any questions thoroughly enough to get this and any other future request out of the way since this sort of software is really the only sort we develop or intend to, we don't produce much non system software and the abstraction models are generally inappropriate for cryptographic or security software. In general, if it comes from Screwjack we would prefer to be as close to the kernel or actual metal as humanly possible if not part of it. Most of our other efforts as detailed below, involve writing the entirety of the kernel on other hardware. That's kind of why the process comes off as an affront to me but I suppose I should realize, this is not most of the use cases encountered.
>>
>> While the present support is the same, the module I need to build presently is already available in another fork but as stated a google funded project not built and signed by us is a significant issue from a security standpoint as they are not a thing I am willing to stake my efforts to in any other way and certainly not as part of the chain linking our cryptography to IOKit and the data of our application users which as I mentioned is a number that is growing at a rate I don't even believe myself. I do about zero to promote anything beyond antagonize intelligence contractors on public forums occasionally. In order to guarantee security I can't ask users to load OSX fuse signed by anyone but Screwjack, period, so I'm sure you can see the problem here. I can legally fork their codebase, and have done so, I've even got a development branch where I have eliminated their dependence on dynamic FUSE libraries which I find ridiculous anyway, the sole reason being supporting fourth party modules on top of the filesystem, which, I find ridiculous and also that is a feature that obviously must be eliminated from this solution to maintain security anyway, considering they presently use it to provide support for customize volume icons, the breach it opens is unacceptable... I also have experience with FUSE kernel and library code on various other architectures and fairly trivially am able to internalize that portion. So this kext cert should be a given; the code is literally already approved in a different build. We're freezing it, forking it, and integrating some. Lest anyone say "but OSXFuse isn't google" - stop them because I am acutely aware of the financial semantics of that relationship; researching them thoroughly falls under part of the service provided with a build of this sort of software. Tl;dr I need to sign a kext nearly identically to but legally not the FUSE kext which is already approved anyway.
>>
>> I say it could be outdated in a week because I don't like the idea of FUSE at all in the first place and I am already well in to efforts on simply porting filesystem support for a native driver that works across all of our supported platforms, I've even been experimenting with UFS but that isn't stable enough universally to provide a solution, unfortunately ext3 is, and the native drivers for that on OS X are deprecated, but not unrevivable...I've nearly got one working, already. Ironically, it was easier for me to resurrect nearly decade old ext2fs code than the project I found that went dead two years ago, I read some inodes, and had a panic, but, from my perspective, that's a sign of life. and since then I've built xnu for everything from yosemite to sierra easily hundreds of times as is and far from as is. I stopped work on that and moved to toolchain regressions and other projects because I'm not interested in developing code for unreleasable solutions. So, that is something that will be done before yesterday at the right time. That would be distributed with the nemesis binary, and also under separate cover because that's easy and people want it.
>>
>> The final frustration I had with the request process is the demand to justify why this is a kext, based on what I've explained all ready, and what I explain next, I'm sure it's not difficult to understand that what I'm doing with regard to cryptography and security is integrally related to security of the underlying system and "trust us" is not a paradigm I can work under. I don't implicitly trust third parties and nobody releasing cryptography has any business doing so, therefore the request to examine other solutions, my only answer to will and can be nothing but, I didn't, because by definition they fail to deliver adequate security margins. I'm not an application developer, Screwjack releases an application, targeted at those who require real and guaranteed security, but we do so, under the belief, that those who require real security, includes every last one of our countrymen in and out of government, and including our enemies.
>>
>> The specific need has evolved some since the initial request and even since the third I've tested now as far back as Yosemite our application build on OS X. I have personally put in a massive amount of research on other avenues entirely, since, while also updating the primary application...this is bothering me also because I did wait until nearly ready to distribute to request, as asked by the dev docs, and having done so expected a rapid turnaround in response. Now, that solution could be outdated by improvements in the next week. Pretty much all of my time is regression testing tools and systems to find a better and priority one more secure way. Things like the dynamic loader privilege escalation (which I am concerned still may exist) are concerns I'm actively trying to mitigate in my development and that is a problem I myself observed again recently while optimizing binaries for size; the new versions of strip are overly cautious, and so, I tested there with my own strip technique on static linkage (i've read the apple position on it and of course have followed that through, I can probably write crt0 for at least three compilers without thinking about it) and have been able to get 1.6mb binaries down to 300kb entirely statically linked in testing, that contain proper mach headers, and execute correctly with the new dynamic loader. These are not application binaries but for my own internal testing working on secure toolchains, I need to be able to static link internally for a number of reasons, I develop systems primarily. Dynamic linking has a place but it isn't everywhere, and I'd be happy to explain the method I used as it may help in optimizing internally; you're welcome entirely to utilize anything I produce, open or closed source - our code is all BSD 2 clause for that reason. I'm presently hoping to take that and optimize the most current openly released LLVM strip utility to be as effective as the GNU tool while preserving the correct headers for the new dyld; that's basically what I achieved with the hex edit after some other steps and some rather tricky builds of standard libraries, of course I had to produce the project to build a libstdc++ first. I've also been working on binary image activators, on several platforms, for several formats. This particularly required some manual intervention with a hex editor, among other things, but, this is something I'm doing in order to ensure that if I release a binary it is something I can personally guarantee to the best of my significant ability is not compromised when it leaves my network and also when it executes. On other platforms, an example of the length I go to to guarantee I can do secure builds, has been to openly swear off further investment in Intel and AMD hardware in the wake of disclosures and EFF concern regarding Management Engine; since then and at considerable expense I've invested in no hardware from those vendors and solely purchased IBM POWER architecture servers (Apple can surely appreciate this architecture, and I have to say I have been seriously impressed with the systems design myself, it's clearly worth the cost), and smaller systems on ARM. Our most popular project by network traffic is on ARM, we have a very successful and fairly wide distributed but completely unadvertised and nameless, baremetal kernel and GSM mobile hardware and software project released under BSD 2 clause entirely, and primarily focused on zero compromise post quantum computing secured messaging using our hardened (one hardening includes addition of parameter sets that replace SHA-1 with full strength BLAKE-256/512 v1, and Skein-1024 using nonstandard lengths to pretty much destroy any effort or hope of an adversary to precompute tables without the hardware becoming a physical impossibility to construct or obtain) NTRU/symmetric hybrids encapsulated over existing widely available network protocols, which Tmobile has been very helpful with debugging. For that system, I went to the extreme of writing the entire startup code in assembly language, including part of the memory allocators, the rest of which were done in C and support multiple stack and heap areas designed around Keil's RTX...the kernel is my work, or forks and ports to ARM entirely by myself, and includes more than one file system driver and what has made it popular I suspect is that some of those drivers of things like SDRAM and filesystems, are not insignificant works and not many entities are giving them away for the public benefit when they execute them successfully. The cryptography library in that, contains many items which have yet to be or already are merged in nemesis and it is leagues ahead of anything else freely available, I can safely say that. Nobody else is releasing an NTRU based public key anything, let alone one offering hardened modes that even consider what we've accomplished, and we're able to exchange keys using a non compromised signal like protocol via MMS using it, on bare metal with complete assurance that our kernel and crypto is not compromised, having 100% audited and authored the code in house. Most of my work is less on applications and more on regression testing toolchains and kernel code, so invariably I will revise whatever solution I arrive at rapidly, and that is why I made the effort to qualify so much. I have access from this work to some of the brightest individuals I am aware of in security and am privileged to have their input regarding my designs and it's often as a direct result of giving away for the public good the work product that results, so, again, should Apple internally find anything useful, by all means, if it solves a problem, that's what I'm releasing it to do, so solve problems with it. I've never minded criticism myself, so long as it's constructive; I won't complain about anything I don't propose a solution to.
>>
>> I respond at length because I'm responding to you surely, but also as you've been kind enough to pass along my request, to anyone in engineering that might find something useful in it or have further questions I could be of assistance answering. The binary optimization stuff is something I do because in doing micro optimization like that, I've found many critical vulnerabilities in my own work every time, just by doing things like going over thousands of lines of code looking for alignment mismatches or types...the irony being i use a  different process a friend calls shotgun debugging, I rough out rapidly prototypes and trainwreck my dev systems but am relentless on debugging prerelease, I'll make it function, and then go back over things until they're to my specs. I've got one toolchain I have for download on a torified gitweb, it's of special interest to security focused engineering types, and not much of an effort but a hack, it's the CompCert verified compiler which builds mathematically proven software. It hadn't been able to produce binaries for 64 bit BSD targets, but could for OSX and I made the minor revision several months ago to add the BSD target based on the existing code for OSX 64 bit as I run BSD and I needed that for a while. The compiler itself is open source and I mean to offer that revision back to inria but it's kind of trifling and I keep forgetting to..the original author is a pretty well known developer in BSD circles. If you have anyone working on even personally, secure tools, it's at qpbt3kpraplo7ias.onion which is a Tor site yes but, I have it hosted on a server adjacent to my desk in a jail dead in the middle of my NAS, it's a hedge against the world, in that, i push my active development work right there, it's my present working copies of my code such that the second i implement it, it goes out. surprisingly that's where i base my numbers off of, and they're growing exponentially. I don't even track the website I linked in the request, and it's our official page...those hits are probably insane. notably, the numbers on the onion have been broken out by project, and it's the security research and cryptography that matters the most, that which I detailed in extreme here, which is why i'm making such a large issue of it here. If nobody had responded to the work, I wouldn't waste your time. For which, I thank you.
>>
>> I trust this settles the need to investigate much further and appreciate the attention to my request, that pretty much nails anything I can think of.
>>
>> Have a good weekend,
>>
>> Jonathan
>>
>>
>>
>> On November 30, 2017 at 7:29 PM devprograms@apple.com wrote:
>>