Debian/Ubuntu: Why was the service renamed from bind9 to named?

charlie derr cderr at simons-rock.edu
Thu Jul 23 14:44:43 UTC 2020


Caveat: i'm far from an expert on compiling, linking, disassembling,
etc... (in fact i know *very* little about these domains), so it's
possible my comment/question below won't even really make sense.

Still, i'm not going to learn more without asking, so...

On 7/23/20 9:49 AM, Michael De Roover wrote:
> The idea is pretty interesting, seems like they provide a repository
> with packages compiled with their own compiler that changes various
> memory-related elements. It is true that memory is usually the culprit
> behind security flaws.
> 
> According to their page at
> https://polyverse.com/products/polymorphing-linux-security/ :
> 
> "Polymorphing takes source code and runs it through a polymorphic
> compiler, changing register usage, function locations, import tables and
> other targets. This produces individually unique binaries that are
> semantically equivalent to the source. Polymorphing applies the compiler
> to the totality of the Linux stack."
> 
> For this to work at all though, they'd have to provide all packages
> simply as source code (why not use the distribution's own source
> repositories?) and compile it on the target. But even then I think it's
> more of a security by obscurity thing. Sure it makes it more difficult
> to exploit a memory flaw by means of automated exploits and other such
> scripts. But nothing stops you from taking the unmodified source code,
> the binary and a disassembler to find out how exactly the resulting
> binary has been changed / polymorphed.

While it would still *technically* be security by obscurity, it would
seem to me that there's some value to this approach because access to
the compiled binary wouldn't necessarily be easy to obtain (especially
if the sysadmin provisioning the system takes extra efforts to *not*
share it with anyone).  Or am i missing something?


> I'm not very familiar with
> reverse engineering and disassemblers but I don't think there's much
> more to it than that, at least to thwart this defense. All of it is
> possible if an attacker can read, retrieve and execute a binary on the
> affected server. The flaws are still there, only their memory locations
> have changed. It would probably defend against script kiddies, but I
> doubt it would keep out a determined attacker.
> 
> Personally I prefer Google's approach to this for Chromium. They
> documented it at
> https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md
> . Implementing programs in memory safe languages where possible is
> something I believe to be a more solid long-term solution. Additionally
> Google's Project Zero team is behind a lot of the security research and
> disclosures. They audit the actual code instead, which I believe to be
> far more suitable.
> 
> While the idea is valid to some extent (and could be worth it in highly
> confidential environments), I wouldn't consider it worth compiling
> everything from source for, with a nonstandard compiler no less. If
> servers would just be updated more often and (security) bug fixes
> actually make their way through to the distribution releases reliably,
> we'd already go a long way I think. Of course there are also
> configuration mistakes that could compromise a network component. From
> what I've seen so far, this seems to be more often the case with those
> leaked databases and whatnot.

Thanks much for this fascinating discussion,
    ~c


> 
> On 7/23/20 2:39 PM, Fred Morris wrote:
>> Perhaps slightly OT, but here's a company which has a whole business
>> model based on one nonobvious (?) reason to compile from source:
>> https://polyverse.com/
>>
>> -- 
>>
>> Fred Morris

-- 
Charlie Derr   Director, Instructional Technology 413-528-7344
https://www.simons-rock.edu Bard College at Simon's Rock
Encryption key: http://hope.simons-rock.edu/~cderr/
Personal writing: https://medium.com/@cderr   Pronouns: he or they
Home landline: 860-435-1427


More information about the bind-users mailing list