Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
L
libotr
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 50
    • Issues 50
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Libraries
  • libotr
  • Issues
  • #23

Closed
Open
Opened Apr 01, 2016 by jvoisin@jvoisin

libotr is using it's own secure memory implementation

As stated in ./src/mem.c :

/* Memory allocation routines for libgcrypt.  All of the session key
 * information gets allocated through here, so we can wipe it out when
 * it's free()d.  We don't use the built-in secmem functions of
 * libgcrypt because you need to declare a fixed amount of it when you
 * start up.
 *
 * Because "secure" and "insecure" allocations from libgcrypt will get
 * handled the same way (since we're not going to be running as root,
 * and so won't actually have pinned memory), pretend all allocated
 * memory (but just from libgcrypt) is requested secure, and wipe it on
 * free(). */

There are also some gems like

static int otrl_mem_is_secure(const void *p)
{
    return 1;
}

or

    /* Wipe the memory (in the same way the built-in deallocator in
     * libgcrypt would) */
    memset(real_p, 0xff, n);
    memset(real_p, 0xaa, n);
    memset(real_p, 0x55, n);
    memset(real_p, 0x00, n);

    free(real_p);

This is dangerous, since a clever compiler can notice that real_p is freed right after memset, and could remove those calls.

I'm quite sure that libcrypt already has everything libotr may want to use to manage memory, without needing to re-invent the wheel.

(from redmine: created on 2014-04-21)

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
4.2
Milestone
4.2
Assign milestone
Time tracking
None
Due date
None
Reference: lib/libotr#23